advertisement
![Challenges of the Electronic Control Unit Development. ETAS INTECRIO | Manualzz Challenges of the Electronic Control Unit Development. ETAS INTECRIO | Manualzz](http://s1.manualzz.com/store/data/068176925_1-8a89ed7bb26a3a1b9ac831a83f3c5efa-360x466.png)
ETAS Understanding INTECRIO
3.1
3.1.1
Challenges of the Electronic Control Unit Development
The electronic control unit development is a highly complex process: Partly because of the constantly increasing requirements of hardware and software, partly because of the development which is frequently spread across several manufacturers and suppliers.
Complexity Through System Requirements
Today, the complete description of an electronic control unit consists of the description of the software to be run on the electronic control unit and the description of the hardware. In most cases, control algorithms and electronic control unit software are closely linked with the target system on which they are executed.
ASCET introduced the first steps to dissolve this mutual dependency by describing the software (the control algorithm) independently of the hardware on which it is to run. ASCET accomplishes this by mapping the signals from the control algorithm onto the signals supplied by the hardware. If it is a rapid prototyping system, the hardware itself is described in a special editor. Different options exist for microcontroller targets.
In the future, this separation of the descriptions of the target hardware and the software will become increasingly more important for the successful implementation of a new electronic control unit.
On the one hand, it allows electronic control unit software and hardware to be
developed in parallel (see Fig. 3-2; the figure is based on the V model). This
shortens the total development time.
Development of electronic systems
Partitioning Integration
Electronic control unit software development
Electronic control unit hardware development
Setpoint encoder and sensor development
Actuator development
...
Fig. 3-2 Overview of the development of electronic systems
INTECRIO V4.7 - User’s Guide 13
ETAS Understanding INTECRIO
On the other hand, the systems themselves become increasingly more complex, and correlations between the different electronic control units are increasing. The number of electronic control units per vehicle as well as the number of functions per electronic control unit constantly increased during recent
Number
Number of functions per vehicle
ECUs per vehicle
Number of functions per electronic control unit
1970 1980 1990 2000 Time
Fig. 3-3 Functions and electronic control units per vehicle (in The Need for
Systems Engineering. An Automotive Project Perspective , Key Note at the 2 nd European Systems Engineering Conference, Munich, H.-
G. Frischkorn, H. Negele, J. Meisenzahl)
Car manufacturers and suppliers are faced with an enormous cost pressure; they are forced to reduce costs by means of reuse and variants. That is, a certain functionality is used for different vehicle types of a car manufacturer, and vehicle variants are created via software properties. The difference between two variants of a vehicle may consist only in the presence or absence of a certain software functionality and the corresponding sensors and actuators.
For this purpose, the hardware-independent development of the functionality is a great advantage since this allows the functionality to be used universally.
The costs can also be reduced by arranging the software components on the smallest possible hardware system. This limits the number of electronic control units in the vehicle, but it may require the distribution of the components of one functionality to several electronic control units.
In addition, new functionality can be added to a vehicle by means of so-called virtual sensors. These are sensors that do not measure their signals, but calculate them. This calculation can be performed by combining physical models with real sensor values. A good example is tire slip. Tire slip cannot be measured, but by combining the tire model with the current acceleration (measured by the electronic stability program ESP) and the current torque (from the engine control), it is possible to calculate the slip.
Today's vehicle can contain up to 120 microcontrollers that are mostly connected with each other via serial bus systems. The execution of a specific control algorithm depends not only on the electronic control unit on which it runs, but also on the inputs and outputs of other electronic control units.
An example of an already distributed control algorithm is the electronic stability program (ESP) and the engine control.
INTECRIO V4.7 - User’s Guide 14
advertisement
Related manuals
advertisement
Table of contents
- 7 About this Document
- 7 Classification of Safety Messages
- 7 Presentation of Instructions
- 8 Typographical Conventions
- 8 Presentation of Supporting Information
- 9 Introduction
- 9 Safety Information
- 9 Correct Use
- 9 Demands on the Technical State of the Product
- 10 Privacy Statement
- 10 Data Processing
- 10 Data and Data Categories
- 11 Technical and Organizational Measures
- 12 Understanding INTECRIO
- 13 Challenges of the Electronic Control Unit Development
- 13 Complexity Through System Requirements
- 15 Complexity Through Distributed Development
- 16 Possible Steps
- 16 Description of Electronic Systems
- 17 Design and Operating Method of Electronic Systems
- 18 Architecture and Description of Electronic Systems
- 20 Application Software
- 23 Platform Software: Hardware Systems
- 23 Connecting Hardware and Software
- 24 Virtual Prototyping
- 25 Target-Close Prototyping
- 25 Advantages of Virtual Prototyping
- 26 Virtual Prototyping and Rapid Prototyping
- 27 INTECRIO in the Development Process
- 28 The INTECRIO Working Environment
- 32 Software Systems
- 32 Modules and AUTOSAR Software Components
- 34 Functions
- 35 Software Systems
- 35 Environment Systems
- 36 Hardware Systems
- 36 System Projects
- 38 Crossbar
- 40 Experimenting with INTECRIO
- 42 INTECRIO and AUTOSAR
- 42 Overview
- 43 RTA-RTE and RTA-OS
- 44 Creating AUTOSAR Software Components (outside INTECRIO)
- 44 Validating Software Components
- 46 What is a Runtime Environment?
- 47 AUTOSAR Elements in INTECRIO
- 47 AUTOSAR Software Components
- 48 Ports and Interfaces
- 48 Sender-Receiver Communication
- 49 Client-Server Communication
- 49 Calibration Parameter Interfaces
- 49 Runnable Entities and Tasks
- 50 Runtime Environment
- 51 The INTECRIO Components
- 52 Connectivity
- 54 Characteristics in the Creation of the Simulink Model
- 55 Contents of the Description File
- 55 ASCET Connectivity
- 56 Characteristics in the Creation of the ASCET Model
- 57 Contents of the Description File
- 57 The Hardware Configurator
- 58 Discontinued Hardware
- 59 HWX Import/Export
- 60 Ethernet Controller and XCP on UDP
- 60 XXX to CAN Gateway
- 60 ES900 Connectivity and Hardware Configurator
- 61 ES900 Configuration in the Hardware Configurator
- 65 Interface Types and Supported Interfaces
- 72 ES800 Connectivity and Hardware Configurator
- 73 ES800 Configuration in the Hardware Configurator
- 77 Interface Types and Supported Interfaces
- 84 PC Connectivity
- 85 The Project Configurator
- 86 Offline Mode
- 86 Modules and SWC
- 86 Functions
- 87 Software Systems and Environments
- 88 System Projects
- 89 Online Mode
- 90 The OS Configurator
- 90 Tasks of the Operating System
- 91 Scheduling
- 91 Tasks
- 92 Cooperative and Preemptive Scheduling
- 94 Data Consistency with Preemptive Scheduling
- 96 Application Modes
- 97 Design of the OS Configurator
- 98 The OSC Editor
- 98 Creating Tasks
- 101 Task Properties
- 103 Setting Up Timer and Software Tasks
- 104 Setting Up Interrupt Service Routines
- 106 The Project Integrator
- 106 The Build Process
- 107 Overview
- 108 Sequence
- 109 ASAM-MCD-2MC Generation
- 110 The ETAS Experiment Environment
- 111 Validation and Verification
- 111 Measuring and Calibrating
- 112 Experimenting with Different Targets
- 115 Environment
- 115 Bypass Experiment
- 116 Fullpass Experiment
- 118 X-Pass Experiment
- 118 Environment
- 118 The Documentor
- 119 RTA-TRACE Connectivity
- 120 SCOOP and SCOOP-IX
- 121 The SCOOP Concept
- 121 The SCOOP-IX Language
- 122 Modules and Interfaces
- 122 Description of the C Code Interface
- 123 Description of Semantic Information
- 123 Model Origin
- 125 Implementation
- 126 Module Data
- 127 Referenced Models
- 127 File
- 132 Creation of SCOOP-IX and Example
- 142 Modeling Hints
- 142 Modeling for INTECRIO
- 142 Modeling with Simulink
- 144 Modeling with ASCET
- 144 Integration of User Code
- 145 Bypass Concept
- 145 ETK Bypass Concept Description
- 145 Bypass Input
- 146 Hook-Based Bypass
- 147 Service-Based Bypass
- 149 Safety Considerations
- 149 Bypass Input Data
- 149 Bypass Calculation
- 149 Bypass Output Data
- 149 Message Copies
- 150 Service-Based Bypass Specifics
- 151 Service Processes for the SBB Implemented as Service Functions
- 152 Controlling the ECU Behavior from INTECRIO
- 152 OS Configuration for Service-Based Bypass V
- 152 Restrictions
- 153 Classical ECU Function Bypass
- 154 Bypass of an Entire ECU Functionality
- 155 Different Rasters
- 157 ECU-Synchronous Write-Back
- 158 Summary
- 160 Glossary
- 160 Abbreviations
- 164 Terms
- 169 Contact Information
- 170 Figures
- 174 Tables
- 175 Index