Related: Automotive Production
In a word-association test, the words "Cosworth Technology" and "racing engines" would probably come up immediately for those who are at all cognizant of the purveyors of superb technology for the world's tracks. Indeed, one of the most-famous engines in the history of Formula One is the DFV (double-four valve) that debuted at the Dutch Grand Prix in a Lotus Cosworth-Ford with Jim Clark at the wheel—a race that he won with a 27-second lead.
It is a common mistake. In 1998 Cosworth was acquired from Vickers by the Audi Group. The racing side of the business, which became "Cosworth Racing," went to Ford. The Audi-owned business, Cosworth Technology, consists of four business units: Castings, Electronics, Engineering, Manufacturing. And while it does produce engines that go blisteringly fast on tracks and on streets (e.g., the 4.2-liter, twin-turbo Audi RS6 engine is put together at the company's plant in Wellingborough, England), there is a lot more to the business, including an extensive testing capability. Yet when one says "testing" in the context of "Cosworth," one might immediately think "dynamometer." Yes, within the Cosworth Technology facility in Novi, Michigan, there are dynos and various other pieces of engine test equipment. And one can't help but look on with some amazement at projects on the floor at Novi such things as a new HEMI engine being fitted into a 1970 Dodge Challenger and work on a supercharger kit for the Ford Focus (Cosworth Technology engineers worked with Ford engineers on the 2.0-liter engine that's under the hood of the now-out-of-production SVT Focus).
But there is a not-insignificant number of people at the Novi site who are as interested in processing speed as they are in horsepower. And when they think of vehicles, they are thinking about the entire vehicle, not just what's under the hood. What's more, they're thinking of the vehicle in production, not just as something that goes out racing. These are people who are involved with developing the TestingWorks end-of-line test system.
"Diagnostics is our fastest growing area." So says Stan Tracy, the firm's director, Diagnostic Systems. What they're working on at Cosworth Technology, he explains, is really something of an end-to-end diagnostics capability, one that literally starts with vehicle engineering (e.g., assessing information from fleets that can be used for development of new product; performing analysis of on-board diagnostics (OBD) systems) to manufacturing (e.g., end-of-line testing; repair bay analysis) to dealerships (e.g., diagnostics; warranty analysis) to, finally, the aftermarket (diagnostics; data loggers). Tracy says that this information could actually be used in a closed-loop arrangement such that it would be possible to make a determination in real-time what problems vehicles on the road are having (based on their visits to dealers for warranty work), which could then be used to drive changes/improvements in products under development. Cosworth Technology has developed products for engineering (DataWorks), production (TestingWorks; RepairWorks), and service (DealerWorks; FleetWorks) applications, all essentially based on the same run-time kernel.
Speaking of run-time kernels...
"This was designed and architected by plant rats," says Scott Bolt, Software Systems manager. He includes himself among that number. He's talking about TestingWorks. This system is claimed to be able to facilitate a 50% reduction in end-of-line test time requirements—and that's on top of the time savings realized, Bolt says, through the installation and implementation period, which is said to be a fraction of what typical systems require. A key aspect of the system is that it is comparatively easy to program—and modify, as required. Ordinarily, it can be the case that someone (an engineer or testing technician) decides what tests need to be made to a vehicle and in what sequence these tests need to be conducted. This person creates a flowchart of the tests and procedures. Then someone else (a programmer) writes the code necessary to make that happen. That's because, as Bolt points out, "the technician can't write C-code." But the programmer doesn't have much of a clue as to what the testing is all about, either. So it is the best of neither worlds.
"With TestingWorks," Bolt says, "the vehicle technician can author his own test system." Yes, even a technician who doesn't have a clue as to what a run-time kernel is. Fundamentally, the developers at Cosworth Technology have created what they call a "Visual Authoring Tool" (VAT). VAT allows people to create programs via the creation of a graphical model: a drag-and-drop approach. Think of there being a series of boxes, with each box representing a test or part of a test sequence. A flow chart is created by sequencing these boxes. All of the code necessary for running the tests are "within" those boxes, invisible to the diagnostic technician or engineer. According to Bolt, the TestingWorks system has been created so that it doesn't matter what hardware is being used or the operating system: PC or hand-held, OS2 or Linux. Or whatever. The person interested in getting the job done—i.e., the tests performed—is really concerned with accurate test results, not with the minutia of programming and computers.