Shawn Liu of National Instruments describes how the speed ofdevelopment of new features in automotive applications are pushing designers towards off-the-shelf design tools and hardware.

When investigating new development tools and techniques to deliver embedded control systems to market, design engineers should look no further than the automotive industry. In this highly competitive market, car makers have begun to introduce new features and technologies at an unprecedented rate as a way to lure in new car buyers.

While increasing fuel economy by a fraction of a percent still has value for the customer, new features such as rear-detection systems, adaptive cruise control, and active suspension systems are also helping to improve the overall driving experience.

At the core of many of these features are electronic control units (ECUs) running embedded control software.

Developing embedded control systems has always been challenging. Traditionally, design engineers have developed their own custom tools to verify the design. Based on custom hardware and software, these systems incur significant costs up front followed by continuing support and maintenance expenses.

Using off-the-shelf technology for testing systems engineers benefit from faster and easier to use development tools.

Uncertainty of delays

Along with these costs, project managers had to deal with the uncertainty of delays introduced with building these extra custom verification tools.

Automotive design engineers needing to efficiently move designs from concept to product have adopted advanced processes such as rapid control prototyping and hardware-in-the-loop (HIL) testing. However, they have added their own twist by using commercially available tools throughout these processes to further streamline the development and reduce time and costs.

The five stages of system development

Off-the-shelf tools can now be used to create robust embedded control prototypes and testing apparatus as part of the embedded system development process. This process can be broken down into 5 basic stages:

• The first stage consists of system definition where design engineers specify and define the requirements for the embedded control system. This is often done with text based file created on a desktop PC. In some instances real-world empirical data is acquired as part of the specifications.
• In the second stage, rapid prototyping, the design engineer develops the control strategy in a simulated environment on the desktop PC or workstation and then creates an initial prototype of the system with real-time hardware.
• In the third stage, the code generation phase, production code is generated and manually tweaked for the target hardware. At this point the production code is running on the target hardware and not on the prototype hardware anymore.
• During the fourth stage, the design engineer will test out the target hardware against a simulated environment. Real-Time hardware is used to simulate the real-world environment that the control system interfaces with.
• Finally, the target hardware is deployed and integrated into the system and final testing is done to ensure that design specifications were met.

Within all five stages, testing plays a vital role. The following information focuses on how off-the-shelf tools can help with the rapid control prototyping and hardware-in-the-loop testing process.

Rapid control prototyping

Initial prototypes are often used to verify new software control strategies as they are developed. With new design ideas, hardware prototypes provide an excellent way to cut down on the number of iterative cycles it takes to develop the software. However, if a design engineer must spend weeks developing this hardware, obviously this negates any time saved.

Commercial off-the-shelf hardware such as CompactPCI and PXI addresses this challenge with modularity and flexibility that allows the engineer to select a suitable dedicated processor and the I/O required - see figure 1. By selecting the right hardware, the design engineer can create a prototype that closely resembles the eventual target hardware.

Fig 1: RT PXI board

For instance, consider a hardware prototype used to develop a new feature for a standard cruise control system. The processor in the prototype must be able to execute the control software deterministically and at a rate similar to eventual target hardware.

With a slower system such as cruise control, this can typically be a mid-level processor such as a 700MHz x86 processor. The prototype hardware must also connect to the sensors and systems in the vehicle.

Communication buses such as CAN are used to connect to things such as the braking system, throttle, and user inputs on the steering wheel. Counters and timer can be used to read the actual speed of the vehicle through an encoder sensor mounted near the wheel.

After the prototyping and targeting processes have been completed, it may seem pointless to test the target hardware against a simulated environment.

However, there are several reasons why HIL testing is used:

• It is unsafe to test the target hardware with the actual system it interfaces with.
• HIL testing can more quickly and easily simulate a variety of situations such as fault conditions for the target hardware.
• One of the actual systems the target hardware interfaces with are not available for testing.

Since HIL test systems simulate the environment for the controller, hardware use for this must also have real-time performance. Similar to rapid control prototyping, these systems also require flexibility and modularity. In some cases, even greater flexibility in I/O is required to address the testing needs of the HIL test system.

Consider the task of developing an active suspension system to deliver a smoother ride for the driver. The active suspension system will couple a hydraulic actuator in parallel with the spring and shock absorber. The embedded controller in this case must react to the road data by pushing back against the road with the hydraulic actuator.

With testing playing a more vital role here, the HIL test system must simulate road data while also accurately recording the performance of the active suspension system. The force exerted by the hydraulic actuator can be measured as well as the temperature and strain. In addition to the I/O required to interface with the controller, additional hardware is used to measure the temperature and strain of the hydraulic actuator.

Graphical programming

Software plays a crucial part in both rapid control prototyping and HIL testing. In both cases, the software development environment needs to have the flexibility to develop custom control algorithms and the ease-of-use to speed development.

Graphical programming tools, such as LabVIEW, are ideal for designing automotive embedded systems. With a heavy emphasis in control algorithms, embedded control systems in automotive electronics are ideal concepts to visualize and develop graphically. Often, in the system definition phase, design engineers first use flow chart diagrams to visualize the embedded control system. Graphical tools that resemble flow charts make it much easier to implement these systems.

At the same time, programming tools like LabVIEW still offer the flexibility to completely customize a control system using built-in functions for control design.

In the previous example with the active suspension system, the HIL test system must simulate the road conditions by sending position data to the embedded controller. This simulated data could be a profile that looks similar to road conditions in an off-road environment. In addition to the road conditions, the HIL test system must also take into account the effects of the spring and shock absorber and how that effects the final position of the vehicle. The behavior of the spring and shock absorber can easily be added by modeling these components in software with transfer functions. By adding the behavior of the spring and shock absorber in-line with road data, the HIL test system creates a much more realistic environment for the active suspension controller - see figure 2.

Fig 2: Model of passive suspension system in LabVIEW

Adapting design techniques

While the examples described above relate to the automotive industry, there's no doubt that they also are used in other industries such as aerospace, biomedical, heavy machinery, etc. As new technologies in these industries are researched and created, the flexibility of commercial off-the-shelf technology will be able to meet these needs going forward.

By using techniques such as rapid control prototyping and HIL testing, design engineers can test the true behavior of the embedded control system. Using off-the-shelf technology for these testing systems, these engineers benefit from the faster and easier development tools, and from the ability to integrate with a wide variety of different hardware and software products.

Fig 3: LabVIEW Real-Time provides control in design

Shawn Liu is real-time product manager at National Instruments.