Auto Electronics

MODEL-BASED DESIGN STREAMLINES DEVELOPMENT OF BODY ELECTRONICS SYSTEMS

When developing body electronics systems, working in stages beginning with model-based system simulation and progressing toward increasingly realistic hardware models can be more effective than the direct construction and testing of working prototypes.

For the PDF version of this article, click here.

While the algorithms used to control body electronics systems are usually thought to be fairly simple, the overall complexity of the full vehicle electrical system has been rapidly increasing. The traditional approach of basing control system design on building and testing prototypes is quickly losing its ability to cope with continually escalating requirements. Model-based design provides a method to model the complete system, including the electromechanical components, the control algorithm, and the communications network, so that the design can be validated and each part of the feature design can be linked to the requirement and verification tests. This approach reduces time to market by ensuring throughout the design process that the control system meets requirements and that the enabling hardware is validated as it becomes available 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 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 at 25% of the total vehicle value and is subsequently expected to increase to 40% 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 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 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, 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 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 inter-face 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 or an external module, 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 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 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 make it necessary to re-verify part or all of the design many times. System-level re-verification 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 a 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 range of design concepts without physical hardware to evaluate many different ideas. Some of these ideas may have been too risky to 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 beyond the conventional approach.

Model-based design makes it possible to model the controller and the plant, including motors, sensors and actuators. For example, by using a graphical representation of a finite state machine where states and transitions form the building blocks of the system, the control logic for a power window system can be developed. 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% 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 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 example, the interactions between the power window system and other features such as the remote control of the windows or potentially the vehicle communication network.

VERIFYING THE MODEL

Once the models are available the verification process can begin. 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 helps to identify and address ambiguities and contradictions in text-based specifications. Let's look at the one-touch up/down requirement.

Auto-up/down requirement: If the up or down command is issued for at least 200 ms and at most 1 s, the controller enters auto behavior and the window has to be fully opened or closed respectively.

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.

Now concentrating on the mode state, you can see that 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 (indicated by the arrow numbered “3”). 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 ms and 1 s after it was actuated.

With model-based design, we can associate requirements, written in Microsoft Word or requirements management systems such as Telelogic's DOORS, with objects in the model that describe 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 was associated with the Stateflow transition, neutral [after(_200 ms,tick) and before(_1 s,tick)].

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 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 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).

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:

“Transition “NEUTRAL [after(_200ms,tick) … & be…”

Full decision coverage. Conditions “after(_200ms,tick)” and “before(_1s,tick)” were never false. The coverage analysis indicated the following:

“Transition “NEUTRAL [after(200ms,tick) … & be…”

Full decision coverage. Condition “before(_1s,tick)” were never false.

So, even running through these additional tests did not provide full coverage on this transition because the condition “before(_1s,tick)” was 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 verify this requirement, four tests were added in which the driver and passenger up and down switches were depressed for only 100 ms and another four tests where they were depressed for 1.5 seconds:

“Transition “NEUTRAL [after(_200ms,tick) … & be…”

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. So one might ask, why did the added tests that kept the switch depressed for more than one second 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),” which 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 because it is already in the manual state, so it will move 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 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 tested the design model in the simulation environment on the embedded application running on the target hardware, verifying its implementation. These tests also can be elaborated to achieve full code coverage and repeated to cover the vehicle's 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 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 re-used 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 use, 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.

CONTINUOUS TESTING

There is a full spectrum of other combinations of hardware and software simulation and testing that can be performed. Rapid-control prototyping is done earlier in the design process to debug and refine the control algorithm in real-time before the software is implemented. Code is generated just for the controller portion of the model and run on a high-speed, real-time prototyping computer. Software-in-the-loop testing involves executing the production code for the controller in an instruction set simulator, debugger, or within the modeling environment itself for non-real-time execution with the plant model and interaction with the user. Processor-in-the-loop testing is similar to software-in-the-loop except that it executes the production code on the target hardware, further gaining confidence in the software implementation of the design.

CONCLUSION

Model-based design makes it possible to meet the ever-increasing demand for more complicated and complex electromechanical comfort and convenience features. This ability is accomplished by providing an environment where algorithm verification and validation can begin before hardware is available. Simulations can be used to quickly evaluate the performance of alternate design concepts and identify and correct problems in the early stages of the design when they are less costly to fix. Hardware-in-the-loop testing can be used to evaluate the impact of the chosen hardware solution on control system performance. The end result is that alternatives can be evaluated and problems corrected much earlier in the design process, reducing the time and cost required for development and enabling on-time delivery of the embedded body electronics systems.

ABOUT THE AUTHORS

Jason Ghidella is a senior team lead for the technical marketing of Simulink and Stateflow products. He has experience with automotive and aerospace companies that adopt model-based design for embedded control systems. Prior to joining The MathWorks in 2000, Ghidella worked as an applications engineer for The MathWorks distributors in Australia and The Netherlands. He received a Ph.D. in Aeronautical Engineering from the University of Sydney, and a Bachelor of Engineering from James Cook University, Australia.

Jon Friedman is the automotive industry marketing manager. He leads the marketing effort to foster industry adoption of The MathWorks tools and model-based design. Before joining The MathWorks, he held various positions at Ford Motor Company that included working on software development research at the Ford Research Lab, working in product development as a vehicle launch leader at plants across North America, and as an electrical engineering supervisor. Friedman also worked as an independent consultant on projects for Delphi, General Motors, Chrysler and the U.S. Tank-Automotive and Armaments Command. He holds a B.S.E., M.S.E. and Ph.D. in Aerospace Engineering as well as a Masters in Business Administration, from the University of Michigan.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish