English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Zendy Plus

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Zendy Tools

Zendy Open

Virtualization allows the simulation of automotive ECUs on a Windows PCexecuting in closed-loop with a vehicle simulation model. This approach enablesto move certain development tasks from road or test rigs and HiL (Hardware inthe loop) to PCs, where they can often be performed faster and cheaper. Renaulthas recently established such a virtualization process for powertrain controlsoftware based on Simulink models. If the number of runnables exceeds athreshold (about 1500) the execution of the virtual ECU is no longer straightforward and specific techniques are required. This paper describes themotivation behind a Simulink model based process, the virtualization processand applications of the resulting virtual ECUs. Domain: Critical TransportationSystems Topic: Processes, methods and tools, in particular: virtual engineeringand simulation 1. Motivation Since 2010, Renault has established a framework todevelop engine control software for Diesel and Gasoline engines [6]. Theframework is heavily based on MATLAB/Simulink and the idea of model-baseddevelopment, which facilitates the carry-over and carry-across of applicationsoftware between software projects. In the Renault EMS architecture software iscomposed in to about 20 functions, such as Air System, Combustion etc. Afunction consists of modules. A module is the smallest testable software unitand contains runnables to be scheduled and executed by the Operating System(Os) of the ECU. The Renault EMS development process includes basically thefollowing steps [5]. 1. Specification of about 200 generic configurable modulesper ECU using MATLAB/Simulink. 2. Generation of C code (EMS applicationsoftware) from all module specifications using MATLAB/Simulink Embedded Coder.3. MiL (Model in the Loop) test and validation of the resulting executablespecifications at module level in a simulated system environment, consideringonly essential interactions with other modules and system environment. This isessentially a back-to-back test to make sure that the Simulink model of amodule and the corresponding production C code show equivalent and intendedbehaviour. To insure software quality, this step is repeatedly performed withsteps 1 and 2, based on the simulation capabilities of MATLAB/Simulink. 4.Configuration of modules to fit to the specific needs of a software project,such as absence or presence of certain components. 5. Integration of generatedconfigured C code and hand-coded platform software (basic software) on suppliedtarget hardware, a real ECU that communicates with other controllers via CANand other busses. 6. Validation and test of all modules on system level usingthe real ECU. In contrast to step 3, the interactions of all modules andinteractions with the system environment are visible then and subject totesting. For example, the Os runs all scheduled runnables then, not just thoseof the modules considered to be 'essential' for a module under test. Criticalassessment of the above process shows that there is a considerable delaybetween delivery of a set of specifications to the software project team (atthe end of step 3) and system-level tests based on an ECU that runs entiresoftware (step 6). Typical delays are weeks or months.

Full Virtualization of Renault's Engine Management Software and Application to System Development