TechnicalArticles
2008-01-06, 16:32
By Jack Wilber [/URL]
Send email to Jon Friedman
Azure maintains its competitive edge by using [U]Model-Based Design (http://www.chess.nl/) to develop a common design environment, automatically generate production code, and reuse approximately 90 percent of its components.
Unifying Design Efforts
When senior engineer Michael Schaefer joined the Controls Team to work on Azure’s powertrain development initiatives, the software development group was a relatively new organization with few established processes, legacy tools, or experienced C programmers. Distributed across multiple locations, including Seattle, Boston, Vancouver, and the United Kingdom, the group had four different projects under way, none of which used the same code or architecture.
To unify these independent projects under a shared architectural framework and promote code reuse, the Azure software development group standardized on MathWorks tools for Model-Based Design. A single architecture would enable Azure to reuse components across its entire line of electric vehicle, series hybrid, and parallel hybrid powertrains. It would also improve communication across the scattered teams and facilitate developing and testing in a decentralized environment.
Azure’s first development initiative following the adoption of Model-Based Design was an electric vehicle powertrain. The Controls Team began the project by gathering the best existing modules from other vehicles. “The exercise of refactoring our software was beneficial on many levels. We were able to spiral in on an architecture that we are finding very robust and adaptable to varying project requirements. We could also identify areas that required improvements in efficiency and implement them systemically, and identify defects and introduce processes and guidelines for rejecting these types of defects at the design stage,” Schaefer explains.
Partitioning the Architecture
One key to increasing design reuse at Azure is the partitioning of the model architecture into three distinct sections: control, operator plant environment (OPE), and diagnostics (Figure 1). “Partitioning the architecture into these subsystems has allowed us to achieve significant reuse and isolate the customization work for each platform in a known, easily repeatable manner,” Schaefer says.
The control layer, created in Simulink and Stateflow, contains all the control algorithms, encompassing subsystems for drivability, transmission, energy storage, modal control, motor control, energy management, and engine control (Figure 2). Because most of the vehicle-specific functionality is isolated in the OPE, the control layer does not change when application hardware changes, but only when algorithms or design ideas change.
The OPE, also built in Simulink, serves as the interface to a powertrain control module (PCM), the underlying hardware platform. By separating the hardware interface from the application layer, the team can rapidly configure the system for a particular hardware platform. Azure has developed MATLAB and Perl scripts that automatically generate an OPE, including target definition, scheduling, and board-support activities.
The diagnostic subsystem is used for debugging. Both the control layer and the OPE contain hooks that provide the diagnostic subsystem with complete access to all relevant data.
http://www.mathworks.com/company/newsletters/digest/2006/nov/images/az_opelib_w.jpg (http://www.mathworks.com/company/newsletters/digest/2006/nov/images/az_opelib_wl.jpg)
Figure 1. Standard OPE libraries, configurable for target definition, as well as for project-specific diagnostics, the scheduler, and the controller. Click on image to see enlarged view.
http://www.mathworks.com/company/newsletters/digest/2006/nov/images/az_control_w.gif (http://www.mathworks.com/company/newsletters/digest/2006/nov/images/az_control_wl.gif)
Figure 2. The control layer. Click on image to see enlarged view.
Developing a New Vehicle Powertrain
With reusable components, automated scripts, and Model-Based Design, Azure engineers have made commissioning a new vehicle an efficient and precise process. Software development begins when the electrical and mechanical teams provide the developers with a mechanization drawing detailing the hardware interface, including all inputs and outputs. The software team then creates a new development branch of its Simulink models, using CVS as the version control system for its Simulink libraries.
Schaefer and his colleagues configure the OPE Simulink model using their automated MATLAB and Perl scripts. The OPE comprises three hardware-support block libraries: calibration, debug, and input/output. Azure has parameterized these Simulink blocks in a standardized manner so that they can automatically generate configuration information for all of them. This level of automation enables them not only to easily port from one platform to another, but also to implement a new platform or project in short order.
Any new functionality required for a particular vehicle is added to the control layer using Simulink and Stateflow as a new unit. Azure software comprises units grouped in subsystems. A unit is any module that adds new functionality. For example, one customer specification for an electric vehicle required the control system to move the vehicle ahead a pre-defined distance—about 12 inches. To implement “inch mode,” Azure engineers added a new unit to the motor control block, which has since been integrated into the base motor control and is selectively activated, via calibrations, on any application that requires this functionality.
Because many Azure systems are safety-related, each module must undergo rigorous testing, verification, and validation before it is approved as a unit. Working from the vehicle specification, engineers use Simulink to develop a plant model of the vehicle, which includes all major components of a hybrid or electric vehicle. They then run non-realtime simulations using the control layer and the plant model to verify basic functionality.
Deploying Production Code on a Real Vehicle
In addition to automatically generating the configuration of the OPE, Azure engineers also automatically generate all the production code for their systems. Using Real-Time Workshop Embedded Coder, they created a fully automated build process for generating production code from their Simulink control system model and integrating it with low-level device drivers before downloading it to the target PCM hardware.
After generating code for the plant model using Real-Time Workshop, the group conducts hardware-in-the-loop tests to verify real-time operation of the system. They then test the control system on a real vehicle. For hybrid vehicles, they first operate the vehicle in standard, gas-engine mode. They then use the engine to charge the batteries for electric mode tests.
After verifying real-world performance, they incorporate any new functionality that has been added for the specific vehicle, such as the inch-mode unit, into the main development stream, where it becomes part of the baseline system for future vehicles.
Reaping the Benefits of Model-Based Design
By automating most of the configuration, simulation, code generation, and verification of their control systems, Azure has implemented an exceptionally efficient development process. In one instance the team completed 50 builds, addressing enhancements, new functionality, and problem resolution, in a month.
“The combination of automated code generation and high levels of component reuse enabled by Model-Based Design lets our comparatively small team take on numerous projects and compete effectively against much larger organizations,” Schaefer says.
The engineering team has dramatically accelerated development cycles. For example, they commissioned two new vehicles, including harness layout and component integration, in two days. Nic Bouchon, Systems Engineering Manager notes, “We certainly surprised our customer, and ourselves to some extent, that we were able to bring two first-build vehicles online and accomplish baseline calibration in such a short period of time.”
Model-Based Design enables team members in multiple locations to collaborate on design and debug. For example, field teams in the U.K. collect data from the CAN bus and send it to engineers in the U.S. and Canada, who use the data to duplicate and diagnose problems in Simulink and implement a fix. They then regenerate the code and send a new version out to the field team in the U.K.
Automatic code generation lets Azure focus on control system design rather than on learning C programming. “Our goal as a company is to generate 100 percent of our code, and for us, Model-Based Design is the next logical step,” Schaefer explains. “At one time, people wrote code in C and then inspected the assembly code, but not any more. Today, we use Real-Time Workshop to generate C code, and while the testing required is still significant, the trend towards not inspecting the code visually is very good indeed. It gives our engineers the ability to compete with trained programmers.”
更多... (http://www.mathworks.com/company/newsletters/digest/2006/nov/azure.html)
Send email to Jon Friedman
Azure maintains its competitive edge by using [U]Model-Based Design (http://www.chess.nl/) to develop a common design environment, automatically generate production code, and reuse approximately 90 percent of its components.
Unifying Design Efforts
When senior engineer Michael Schaefer joined the Controls Team to work on Azure’s powertrain development initiatives, the software development group was a relatively new organization with few established processes, legacy tools, or experienced C programmers. Distributed across multiple locations, including Seattle, Boston, Vancouver, and the United Kingdom, the group had four different projects under way, none of which used the same code or architecture.
To unify these independent projects under a shared architectural framework and promote code reuse, the Azure software development group standardized on MathWorks tools for Model-Based Design. A single architecture would enable Azure to reuse components across its entire line of electric vehicle, series hybrid, and parallel hybrid powertrains. It would also improve communication across the scattered teams and facilitate developing and testing in a decentralized environment.
Azure’s first development initiative following the adoption of Model-Based Design was an electric vehicle powertrain. The Controls Team began the project by gathering the best existing modules from other vehicles. “The exercise of refactoring our software was beneficial on many levels. We were able to spiral in on an architecture that we are finding very robust and adaptable to varying project requirements. We could also identify areas that required improvements in efficiency and implement them systemically, and identify defects and introduce processes and guidelines for rejecting these types of defects at the design stage,” Schaefer explains.
Partitioning the Architecture
One key to increasing design reuse at Azure is the partitioning of the model architecture into three distinct sections: control, operator plant environment (OPE), and diagnostics (Figure 1). “Partitioning the architecture into these subsystems has allowed us to achieve significant reuse and isolate the customization work for each platform in a known, easily repeatable manner,” Schaefer says.
The control layer, created in Simulink and Stateflow, contains all the control algorithms, encompassing subsystems for drivability, transmission, energy storage, modal control, motor control, energy management, and engine control (Figure 2). Because most of the vehicle-specific functionality is isolated in the OPE, the control layer does not change when application hardware changes, but only when algorithms or design ideas change.
The OPE, also built in Simulink, serves as the interface to a powertrain control module (PCM), the underlying hardware platform. By separating the hardware interface from the application layer, the team can rapidly configure the system for a particular hardware platform. Azure has developed MATLAB and Perl scripts that automatically generate an OPE, including target definition, scheduling, and board-support activities.
The diagnostic subsystem is used for debugging. Both the control layer and the OPE contain hooks that provide the diagnostic subsystem with complete access to all relevant data.
http://www.mathworks.com/company/newsletters/digest/2006/nov/images/az_opelib_w.jpg (http://www.mathworks.com/company/newsletters/digest/2006/nov/images/az_opelib_wl.jpg)
Figure 1. Standard OPE libraries, configurable for target definition, as well as for project-specific diagnostics, the scheduler, and the controller. Click on image to see enlarged view.
http://www.mathworks.com/company/newsletters/digest/2006/nov/images/az_control_w.gif (http://www.mathworks.com/company/newsletters/digest/2006/nov/images/az_control_wl.gif)
Figure 2. The control layer. Click on image to see enlarged view.
Developing a New Vehicle Powertrain
With reusable components, automated scripts, and Model-Based Design, Azure engineers have made commissioning a new vehicle an efficient and precise process. Software development begins when the electrical and mechanical teams provide the developers with a mechanization drawing detailing the hardware interface, including all inputs and outputs. The software team then creates a new development branch of its Simulink models, using CVS as the version control system for its Simulink libraries.
Schaefer and his colleagues configure the OPE Simulink model using their automated MATLAB and Perl scripts. The OPE comprises three hardware-support block libraries: calibration, debug, and input/output. Azure has parameterized these Simulink blocks in a standardized manner so that they can automatically generate configuration information for all of them. This level of automation enables them not only to easily port from one platform to another, but also to implement a new platform or project in short order.
Any new functionality required for a particular vehicle is added to the control layer using Simulink and Stateflow as a new unit. Azure software comprises units grouped in subsystems. A unit is any module that adds new functionality. For example, one customer specification for an electric vehicle required the control system to move the vehicle ahead a pre-defined distance—about 12 inches. To implement “inch mode,” Azure engineers added a new unit to the motor control block, which has since been integrated into the base motor control and is selectively activated, via calibrations, on any application that requires this functionality.
Because many Azure systems are safety-related, each module must undergo rigorous testing, verification, and validation before it is approved as a unit. Working from the vehicle specification, engineers use Simulink to develop a plant model of the vehicle, which includes all major components of a hybrid or electric vehicle. They then run non-realtime simulations using the control layer and the plant model to verify basic functionality.
Deploying Production Code on a Real Vehicle
In addition to automatically generating the configuration of the OPE, Azure engineers also automatically generate all the production code for their systems. Using Real-Time Workshop Embedded Coder, they created a fully automated build process for generating production code from their Simulink control system model and integrating it with low-level device drivers before downloading it to the target PCM hardware.
After generating code for the plant model using Real-Time Workshop, the group conducts hardware-in-the-loop tests to verify real-time operation of the system. They then test the control system on a real vehicle. For hybrid vehicles, they first operate the vehicle in standard, gas-engine mode. They then use the engine to charge the batteries for electric mode tests.
After verifying real-world performance, they incorporate any new functionality that has been added for the specific vehicle, such as the inch-mode unit, into the main development stream, where it becomes part of the baseline system for future vehicles.
Reaping the Benefits of Model-Based Design
By automating most of the configuration, simulation, code generation, and verification of their control systems, Azure has implemented an exceptionally efficient development process. In one instance the team completed 50 builds, addressing enhancements, new functionality, and problem resolution, in a month.
“The combination of automated code generation and high levels of component reuse enabled by Model-Based Design lets our comparatively small team take on numerous projects and compete effectively against much larger organizations,” Schaefer says.
The engineering team has dramatically accelerated development cycles. For example, they commissioned two new vehicles, including harness layout and component integration, in two days. Nic Bouchon, Systems Engineering Manager notes, “We certainly surprised our customer, and ourselves to some extent, that we were able to bring two first-build vehicles online and accomplish baseline calibration in such a short period of time.”
Model-Based Design enables team members in multiple locations to collaborate on design and debug. For example, field teams in the U.K. collect data from the CAN bus and send it to engineers in the U.S. and Canada, who use the data to duplicate and diagnose problems in Simulink and implement a fix. They then regenerate the code and send a new version out to the field team in the U.K.
Automatic code generation lets Azure focus on control system design rather than on learning C programming. “Our goal as a company is to generate 100 percent of our code, and for us, Model-Based Design is the next logical step,” Schaefer explains. “At one time, people wrote code in C and then inspected the assembly code, but not any more. Today, we use Real-Time Workshop to generate C code, and while the testing required is still significant, the trend towards not inspecting the code visually is very good indeed. It gives our engineers the ability to compete with trained programmers.”
更多... (http://www.mathworks.com/company/newsletters/digest/2006/nov/azure.html)