Media Newsletters - Sept 2006
Streamlined Development of Body Electronics Systems Using Model-Based Design
by Jason R. Ghidella and Jon Friedman
Although the algorithms that control body electronics systems are generally regarded as simple, the electrical system for an automobile has become far more complex with escalating requirements. The traditional approach to control system design, which relies on building and testing prototypes, is losing its ability to cope with the increased complexity. Model-Based Design provides a method for modeling the complete system, including the electromechanical components, control algorithm, and communications network, to validate the design and link each part of it to requirement and verification tests. This approach reduces time-to-market by ensuring that the control system meets requirements and enabling hardware validation through hardware-in-the-loop testing.
Body Electronics Increasing in Complexity
Control system design was hardly a factor in the implementation of traditional body electronics systems. Modules were not needed to control traditional comfort and convenience features, such as windows that went up and down with the push of a button. This algorithm is neither challenging nor difficult. The essence of the design challenge for traditional features lies in the packaging and physics. But as features are added or enhanced, more sophisticated control systems are required.
According to a recent study by the global research firm, Research and Markets, the electrical and electronic content of automobiles is already at 25 percent of the total vehicle value and is subsequently expected to increase to 40 percent by 2010. The number of microprocessors in current model vehicles ranges from approximately 30 in an economy car to more than 100 in a luxury vehicle. The average car already has more than 35 million lines of code and automakers spend $2 billion to $3 billion a year fixing software problems.
Today there is customer expectation that power windows will include advanced features such as one-touch-up or one-touch-down, where the window continues up or down even after the customer has released the window switch. Some automobiles also offer global-open or global-close features, allowing all windows and the sunroof to be opened or closed with the touch of a single button. In addition to the customer requirements for these features, power windows with these enhanced capabilities must also meet federally regulated safety requirements, such as object detection. When an object is detected in the window’s path as it is being closed, the window must immediately stop and then lower to a specified distance. To meet these additional requirements, extra sensors and control logic are needed, further complicating the design.
Role of Interface Requirements
The complexity of the design challenge is increased by the interface requirements of these enhanced features. Interface requirements arise when one feature requires information from other features. For example, many new vehicles have a feature that continues to power the window motors after the key is removed from the ignition so that the windows can be raised or lowered without the need to reinsert the key into the ignition. Safety regulations require that the control system prevent the windows from being operated when the driver or passenger doors are open. If the door open/close status is monitored by a different module than the window motion controller, the two modules will have to communicate, resulting in an interface requirement. In this situation, the control system must be able to meet customer expectations for immediate window movement, while reading inputs from other modules and taking potential processing delays into account.
Control system algorithms have had to evolve to a much higher level of complexity to support these additional requirements. The fundamental architecture also has had to change since a microprocessor, either embedded in the motor itself or an external module, now must be used to control the window motor. Of course, the traditional physical packaging and motor sizing requirements must still be met, to ensure that the window rises at a sufficient speed.
Waiting for the Last Piece of Hardware
The traditional method of control system design involves writing specifications in text, then developing algorithms in C or C++. But software algorithms cannot be verified without hardware. To verify a network and the interactions between modules, all of the hardware, including both modules and plants (the electromechanical component under control), must be assembled. Systems are either tested on a breadboard, where the electronic components are laid out, or on a prototype vehicle. This process means that with the traditional approach of component verification cannot be started until the hardware is available. Likewise, the overall system cannot be verified until the last piece of hardware is available, including the wiring.
Late design changes typically make it necessary to reverify part or all of the design many times. System-level reverification must be performed partly because fixes to one module can cause issues for other modules or uncover other failures when they are tested as part of complete system. Often there is not time to verify that the requirements are met for all of the buildable combinations, which on high-end vehicles can number in the hundreds to thousands. As a result of this complexity, many potential combinations go untested until they are built in production. The result is that with the traditional process problems are often found late, changes are made later, and full verification is put at risk. Moreover, the cost of making changes at the later stages of the design process is often orders of magnitude higher than if the problems had been detected earlier, and there is not an easy way to fully account for the cost of an issue that escapes to the customer. Warranty costs can be tracked, but the loss of customer satisfaction and confidence in the product and company can take a long time to fix.
Advantages of Model-Based Design
Model-Based Design helps body electronics designers overcome these challenges by enabling a hierarchical approach in which the design is initially defined at a very high level and blocks are added as necessary to provide more functional details. The model of the component being designed becomes an executable specification that designers can rapidly modify and evaluate by simulating it in a larger system model. Engineers can quickly evaluate the performance of a wide range of design concepts without physical hardware to evaluate many different ideas. Some of these ideas may have been too risky to even consider using the traditional development approach. The simulation testing can be automated and repeated without manual effort whenever the design is changed or can be used to verify buildable combinations. This approach provides the potential ability to optimize the design far beyond the conventional approach.
Model-Based Design makes it possible to model both the controller and the plant, including motors, sensors, and actuators. For example, the control logic for a power window system can be developed by using a graphical representation of a finite state machine where states and transitions form the building blocks of the system. The plant can be described by a series of electrical and mechanical components to represent a DC motor connected to the scissor mechanism that moves the window glass up and down. The control system model is a hybrid of continuous time and finite state logic and the plant model uses continuous time dynamics.
Anecdotal evidence shows that at least 70 percent of control system software problems are caused by incomplete, incompatible, ambiguous, contradictory, and untested requirements. Incorporating the specifications and tests that verify these requirements in the model itself helps to validate the specifications and ensures that they are met at each stage of the design process. To fully verify the feature or component design, we must also model the external system requirements, for instance, the interactions between the power window system and other features such as the remote control of the windows and potentially the vehicle communication network.
Verifying the Model
Once the models are available, we can begin the verification process. The following example shows how a power window control system model was subjected to various test cases representing driver and passenger commands. Note how Model-Based Design forces you to think through the whole design, which often helps to identify and address ambiguities and contradictions in text-based specifications. Let’s look at the one-touch-up/down requirement:
Table 1: Auto-up/down requirement.The logic describing the movement of the window has been formulated in Stateflow® using a finite state machine as shown in Figure 1. The Move state contains two parallel substates, Direction and Mode, which are independent of each other, but interrelated. Direction determines whether the windows go up or down while Mode determines whether the window controller is in manual or auto mode. The Move state also contains the function obstacles, which is continually being evaluated to detect if an obstacle is in the window’s path.
Figure 1. Stateflow logic to determine the movement of the controller.
Looking at the Mode state in more detail, the substate NotSureYet is the default state the controller enters. It will transition out of this state to either the Auto state, Manual state, or leave the Move state completely and enter the Stop state. These transitions are gated based on events and conditions. The transition highlighted in red gates the controller’s one-touch up/down requirement. The controller will only move into the Auto state if the switch has been released, issuing the NEUTRAL event, between 200 milliseconds and 1 second after it was actuated.
With Model-Based Design, we can associate requirements, written in Microsoft Word or requirements management systems such as Telelogic DOORS, with objects in the model that describes their behavior. These associations can also embed navigation links that point to each other, making it easy to trace the requirement to the design and vice-versa. So for this example, the one-touch up/down requirement described in Table 1, was associated with the Stateflow transition, NEUTRAL [after(_200ms,tick) & before(_1s,tick)].
Figure 2. The Auto Up-Driver test case is associated with requirements and assertions to check design outputs.
Now let’s embed test cases for this requirement in the model to verify the one-touch up/down feature. Since the requirement is for both up and down, and either the driver or passenger could activate this feature, four tests will need to be created. In Figure 2, the test case where the driver’s “up” switch has been depressed for 400 ms and then released is defined. The bottom signal in the test case, “do_verification,” enables the verification blocks to check that the controller is in the expected states, which are shown on the top right pane of the figure. For this test case, the controller should be in the Auto and Move_Up states while not in the Manual, Move_Down, or Stop states. On the bottom right pane, the requirement associated with this test case is shown. By double clicking on the requirement, you navigate to the location in the document describing it. Similar tests were set up for the three other scenarios that involve the one-touch up/down requirement.
By running these tests on the model, if the controller outputs do not match the expected results the test will stop and a message will appear, directing the user to the part of the design that did not perform as expected. If the test runs through to completion, the design performs as expected and meets the requirement being tested.
This process raises the question: if all the tests run to completion without any errors, has the design been fully tested? Coverage analysis tools can be used to measure the completeness of test routines. Figure 3 shows the coverage analysis results displayed directly in the model. Color highlighting is used to show the logic paths that have full coverage (green) as well as those that have not been fully tested (red).
Figure 3. Coverage metrics displayed in the context of the design.
The results show that the transition to the Auto state has not been fully tested. Clicking on the transition displays additional information in a dialog box:
Full decision coverage. Conditions "after(_200ms,tick)" and "before(_1s,tick)" were never false.
This analysis indicates that additional tests are needed to verify that the algorithm does not enter the Auto state when the switch is depressed for less than 200 ms or more than one second. To fully verify this requirement, four tests were added in which the driver and passenger up and down switches were depressed for only 100ms and another four tests where they were depressed for 1.5 seconds.
Full decision coverage. Condition "before(_1s,tick)" were never false.
However, coverage analysis showed that even running through these additional test cases still provided full coverage on this transition because the condition “before(_1s, tick)” was never false. One might ask why the added tests that kept the switch depressed for more than one second did not register in the coverage analysis.
The answer lies in the design. One of the other transitions originating from the NotSureYet state has a condition “after(_1s,tick)” that evaluates true as soon as a switch is depressed for more than one second and moves the controller into the Manual mode. Through this analysis of the algorithm, we see when the switch is depressed for more than one second and then released, the Neutral event is issued. This does not cause the controller to transition to the Auto state, but rather it moves it completely out of the Move state into the Stop state. As a result, we can simplify our design by removing unnecessary complexity to provide a transition to the Auto state as:
NEUTRAL [after(_200ms,tick)]
Optimizing the Model and Generating the Production Code
In addition to developing control algorithms, models can be used to conduct system-level design trade offs using either Monte Carlo simulation methods or optimization routines. Typical performance objectives include minimizing cost and power consumption while maximizing the lifetime of the parts and meeting all design requirements. Powerful optimization algorithms can be used to precisely determine where the optimal design resides. For example, a design study could be conducted on several different motors or microprocessors to determine if less expensive components could still meet the performance objectives.
Once the system is fully designed, C-code can be generated for the target hardware. Automatic code generation has matured to the point where its efficiency compared to hand code is no longer an issue. As a result, the consistency and efficiency of the code no longer depend on the quality of the software coder and the time required to produce software updates is dramatically reduced.
Next, engineers can reuse the test cases that fully tested the design model in the simulation environment on the embedded application running on the target hardware, verifying its implementation. In addition, these tests can be elaborated to achieve full code coverage and repeated to cover the buildable combination complexity.
Adding Hardware
So far, we have focused on simulation-based testing, without physical components. At this point in the design cycle, it is important to add in hardware in order to test how the controller software will operate in the real world. Even if not all hardware is available, hardware testing can occur, as the missing devices can be emulated in what is commonly referred to as hardware-in-the-loop (HIL) testing. This is where the model of the device (plant model) that was used in the simulation testing is ported to a real-time simulation device with I/O ports to emulate the I/O connections of the physical plant. The control module, if available, or the prototype controller (rapid prototyping), can then be connected to the plant (be it the real or simulated component) and the same test routines can once again be reused in the HIL testing to verify that the addition of real-time constraints has not uncovered any design flaws.
It is important to note that hardware testing is focused on testing the hardware instantiation of the design, as opposed to debugging the algorithm or the software, which was required at this stage in the past. The focus is typically on addressing network and physical timing, power consumption, RAM and ROM usage, central processor utilization, environment requirements such as heating and physical durability, and final algorithm tuning.
Obviously the accuracy of simulation, as well as the HIL testing, is limited by the fidelity of the plant models used throughout Model-Based Design. For this reason, as soon as they became available, prototype or production components, such as the window motor, mechanism, and window, can be substituted for the corresponding portions of the plant model on the HIL system. This makes it possible to easily detect and fix discrepancies between the model and the hardware implementation. Model-Based Design does not eliminate the need for prototype hardware, but it significantly reduces the amount of hardware needed.
