RSS_Auto_Poster
Well-known member
Written by Joe Fairchild
The use of the AUTOSAR standard is well known for its business benefits, but it also presents many improvements for the software engineering side of the integrated development process. These include maximum code re-use, employment of off-the-shelf software stacks, and the creation of hardware-independent applications. The standard also introduces numerous opportunities to improve embedded electronic systems in vehicles including the early testing of software code. Testing earlier in the development process, using virtual validation without expensive physical electronic control unit (ECU) prototypes, can speed up the development cycle, save time, and increase the potential for a functional design. With growing system complexity, testing code earlier in the development phase is an ongoing issue for engineers. That testing process is usually split into two segments: component and system-level testing. It is usually difficult to perform system-level functional testing without hardware components. That"s because the code often contains calls to low-level drivers that won"t work without ECU hardware, or the code needs an operating system to trigger calls to the function to be tested. Today, development time constraints and ongoing functional sophistication requirements dictate that component integration tests are performed in realistic scenarios to get useful simulation data early in development. Virtual function validation of AUTOSAR application software modules, using commercially available tools, can help meet these requirements. There are two key features of AUTOSAR that enable virtual validation. The first is the standardization of interfaces. This means that any function call, memory access, or hardware driver action that accesses a feature external to the current application component will do so in a standardized way. The second is the meta model for system architecture modeling. This allows use of XML (or an off-the-shelf tool) to specify information about existing code such as which data are input or output by the code, or what triggering behavior activates it, etc. Using AUTOSAR, developers can be aware of everything going into and coming out of each of piece of an application in a standardized format. Having a standardized way to access production-intent code in a hardware-dependent way has led to the creation of new tools and execution environments that can run simulations with realistic ECU behavior. It has also led to the extension of existing platforms such as rapid control prototyping devices and hardware-in-the-loop (HIL) systems by applying the use of "virtual ECUs" to in-vehicle prototyping and mixed networks of real and virtual ECUs during HIL testing. In addition to the standardization of application code through AUTOSAR, standards such as FMI (Functional Mock-up Interface), ASAM (Association for Standardization of Automation and Measuring Systems) XCP (Universal Measurement and Calibration Protocol), and ASAM HIL API (application programming interface) are used by virtual validation execution platforms to connect to plant models and interface with tools already in use during hardware testing. This enables a developer to validate the AUTOSAR software components under development, in a closed loop, and connect to a powerful suite of functional test tools already employed in the HIL area including complex and realistic plant, environmental, visualization, or test automation models. So regardless of where you are along the path to using AUTOSAR, there is a new light at the end of the testing tunnel in the form of virtual validation. Joe Fairchild of dSPACE Inc. wrote this article for Automotive Engineering.
Date: 09-Jun-2015 12:50 EDT
More of this article on the SAE International website
ID: 1317
The use of the AUTOSAR standard is well known for its business benefits, but it also presents many improvements for the software engineering side of the integrated development process. These include maximum code re-use, employment of off-the-shelf software stacks, and the creation of hardware-independent applications. The standard also introduces numerous opportunities to improve embedded electronic systems in vehicles including the early testing of software code. Testing earlier in the development process, using virtual validation without expensive physical electronic control unit (ECU) prototypes, can speed up the development cycle, save time, and increase the potential for a functional design. With growing system complexity, testing code earlier in the development phase is an ongoing issue for engineers. That testing process is usually split into two segments: component and system-level testing. It is usually difficult to perform system-level functional testing without hardware components. That"s because the code often contains calls to low-level drivers that won"t work without ECU hardware, or the code needs an operating system to trigger calls to the function to be tested. Today, development time constraints and ongoing functional sophistication requirements dictate that component integration tests are performed in realistic scenarios to get useful simulation data early in development. Virtual function validation of AUTOSAR application software modules, using commercially available tools, can help meet these requirements. There are two key features of AUTOSAR that enable virtual validation. The first is the standardization of interfaces. This means that any function call, memory access, or hardware driver action that accesses a feature external to the current application component will do so in a standardized way. The second is the meta model for system architecture modeling. This allows use of XML (or an off-the-shelf tool) to specify information about existing code such as which data are input or output by the code, or what triggering behavior activates it, etc. Using AUTOSAR, developers can be aware of everything going into and coming out of each of piece of an application in a standardized format. Having a standardized way to access production-intent code in a hardware-dependent way has led to the creation of new tools and execution environments that can run simulations with realistic ECU behavior. It has also led to the extension of existing platforms such as rapid control prototyping devices and hardware-in-the-loop (HIL) systems by applying the use of "virtual ECUs" to in-vehicle prototyping and mixed networks of real and virtual ECUs during HIL testing. In addition to the standardization of application code through AUTOSAR, standards such as FMI (Functional Mock-up Interface), ASAM (Association for Standardization of Automation and Measuring Systems) XCP (Universal Measurement and Calibration Protocol), and ASAM HIL API (application programming interface) are used by virtual validation execution platforms to connect to plant models and interface with tools already in use during hardware testing. This enables a developer to validate the AUTOSAR software components under development, in a closed loop, and connect to a powerful suite of functional test tools already employed in the HIL area including complex and realistic plant, environmental, visualization, or test automation models. So regardless of where you are along the path to using AUTOSAR, there is a new light at the end of the testing tunnel in the form of virtual validation. Joe Fairchild of dSPACE Inc. wrote this article for Automotive Engineering.
Date: 09-Jun-2015 12:50 EDT
More of this article on the SAE International website
ID: 1317
