Consider a transmission control module (TCM). This type of ECU controls the car’s transmission system so it’s always in the best possible gear to increase performance and fuel economy.
These are some of the typical inputs and outputs of a transmission control module:
Input | Output |
---|
VSS–Vehicle Speed Sensor
WSS–Wheel Speed Sensor
TPS–Throttle Position Sensor
ISS–Input Speed Sensor
TFT–Transmission Fluid Temperature Sensor
Kick Down Switch
Brake Light Switch
Cruise Control System
Engine Control Unit
Other ECUs (Automotive Buses)
| Shift Lock
Shift Solenoids
Pressure Control Solenoids
Torque Converter Clutch
Engine Control Unit
Other ECUs (Automotive Buses)
|
Table 1: Typical Inputs and Outputs of a TCM
Abstracting the signal types, this is a more graphical representation of the same TCM.
Figure 2: Representation of the Typical Functional Blocks of a TCM
Figure 3: Simplified View of TCM Inputs and Outputs
The summary of inputs and outputs shows a list of test system core requirements: instrumentation, switching, loads, and the controller that executes the test software and test sequence.Figure 4: Core Functional Blocks of Instrumentation, Loads, and Switches to Test a Typical TCM
Given the considerable repetition of elements across different ECUs, the elements of the test system are also similar. This at least creates the ability to standardize at the hardware level. However, large standardization efforts require much more than just aligning on hardware and the use of it. They also involve corporate strategy, vendor relationships, risk management, and many other dependencies.
That’s when standardizing at the software level becomes a more reasonable and attainable aspiration. Figure 5 shows a fuller representation of what can beexpected from the production test system.
Figure 5: Common Elements of a TCM's Production Test System
To provide an initial system to perform the functions represented by the blocks in Figure 4, virtually all vendors in the ECU production test market offer Tier 1s their hardware and software. They claim that approach delivers the best compatibility while ensuring “enough” openness. Most of them also provide closed boxes that run their own firmware for stand-alone operation, though that’s not necessary during production test and adds unnecessary cost.
For this approach to work, companies need to assess their systems from the differentiation point of view. Though vendors can offer the same hardware and software to any company that needs them, the Tier 1 and, most importantly in this case, the test development group must differentiate and gain a competitive advantage. When the test system is assessed first for its software, owning the architecture for it becomes a major step in market differentiation.
When companies focus on software as the standard and offload the hardware selection to the vendor so that it comes with a proposal, the test development group can spend its time ensuring the software is adaptable and flexible for future requirements that the hardware should be able to meet anyway.
For example, test development groups can focus on building a test framework that includes a measurement and hardware abstraction layer to make it hardware agnostic, creating plug-ins to ensure that the test system can seamlessly connect to the manufacturing execution system (MES) at the facility where it will be deployed, and creating standard operator interfaces that adapt to language, ECU, type of test, reporting, and so on.
Best-in-class vendors offer openness in their products to provide a higher-level starting point for test engineers. This helps engineers concentrate on the software development instead of implementation details like the wiring of loads, instruments, and so on. As mentioned, they focus on abstraction layers, frameworks, compatibility with company-specific tools, and so on.
Figure 6: A higher level of integration helps test engineers focus on differentiating through software instead of spending time on system configuration, procurement and wiring.