advertisement
INTECRIO V4.6
User’s Guide
2
Copyright
The data in this document may not be altered or amended without special notification from ETAS GmbH. ETAS GmbH undertakes no further obligation in relation to this document. The software described in it can only be used if the customer is in possession of a general license agreement or single license. Using and copying is only allowed in concurrence with the specifications stipulated in the contract.
Under no circumstances may any part of this document be copied, reproduced, transmitted, stored in a retrieval system or translated into another language without the express written permission of ETAS GmbH.
© Copyright 2016 ETAS GmbH, Stuttgart
The names and designations used in this document are trademarks or brands belonging to the respective owners.
The name INTECRIO is a registered trademark of ETAS GmbH.
M ATLAB and Simulink are registered trademarks of The MathWorks, Inc.
Document EC020001 V4.6 R02 EN - 06.2016
ETAS Contents
Contents
Correct Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Labeling of Safety Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Demands on the Technical State of the Product. . . . . . . . . . . . . . . . 8
Challenges of the Electronic Control Unit Development . . . . . . . . . . . . . . . . 10
Complexity Through System Requirements . . . . . . . . . . . . . . . . . . 10
Complexity Through Distributed Development. . . . . . . . . . . . . . . . 12
Possible Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Design and Operating Method of Electronic Systems . . . . . . . . . . . 14
Architecture and Description of Electronic Systems . . . . . . . . . . . . 15
Application Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Platform Software: Hardware Systems . . . . . . . . . . . . . . . . . . . . . . 20
Connecting Hardware and Software . . . . . . . . . . . . . . . . . . . . . . . 20
Target-Close Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Advantages of Virtual Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . 22
Virtual Prototyping and Rapid Prototyping . . . . . . . . . . . . . . . . . . . 23
INTECRIO in the Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
The INTECRIO Working Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Software Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Modules and AUTOSAR Software Components . . . . . . . . . . . . . . . 29
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Software Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Environment Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Hardware Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
INTECRIO V4.6 - User’s Guide 3
4
Contents ETAS
System Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Crossbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Experimenting with INTECRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
RTA-RTE and RTA-OS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Creating AUTOSAR Software Components (outside INTECRIO) . . . 42
Validating Software Components . . . . . . . . . . . . . . . . . . . . . . . . . 42
What is a Runtime Environment? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
AUTOSAR Elements in INTECRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
AUTOSAR Software Components . . . . . . . . . . . . . . . . . . . . . . . . . 45
Ports and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Sender-Receiver Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Client-Server Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Calibration Parameter Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Runnable Entities and Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Inter-Runnable Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Runtime Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
M ATLAB
® /Simulink ® Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Characteristics in the Creation of the Simulink Model . . . . . . . . . . 52
Contents of the Description File. . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Characteristics in the Creation of the ASCET Model. . . . . . . . . . . . 55
Contents of the Description File. . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.2
HWX Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Ethernet Controller and XCP on UDP . . . . . . . . . . . . . . . . . . . . . . . 57
XXX to CAN Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
ES1000 Connectivity and Hardware Configurator . . . . . . . . . . . . . . . . . . . . 58
Configuring the ES1000 in the Hardware Configurator . . . . . . . . . 59
Board Types and Supported Boards . . . . . . . . . . . . . . . . . . . . . . . . 62
ES900 Connectivity and Hardware Configurator . . . . . . . . . . . . . . . . . . . . . 67
ES900 Configuration in the Hardware Configurator. . . . . . . . . . . . 68
Interface Types and Supported Interfaces. . . . . . . . . . . . . . . . . . . . 71
RTPRO-PC Connectivity and Hardware Configurator . . . . . . . . . . . . . . . . . . 78
RTPRO-PC Configuration in the Hardware Configurator. . . . . . . . . 78
Interface Types and Supported Interfaces. . . . . . . . . . . . . . . . . . . . 81
Offline Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Modules and SWC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Software Systems and Environments . . . . . . . . . . . . . . . . . . . . . . . 88
System Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Online Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
INTECRIO V4.6 - User’s Guide
ETAS Contents
Tasks of the Operating System. . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Cooperative and Preemptive Scheduling . . . . . . . . . . . . . . . . . . . . 93
Data Consistency with Preemptive Scheduling . . . . . . . . . . . . . . . . 94
Application Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Design of the OS Configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 4.9.2
The OSC Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Creating Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Task Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Setting Up Timer and Software Tasks. . . . . . . . . . . . . . . . . . . . . . 104
Setting Up Interrupt Service Routines (RTA-OSEK/ES900 and
RTA-OSEK/RTPRO-PC without SWC only). . . . . . . . . . . . . . . . . . . 105
The Build Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
ASAM-MCD-2MC Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.11 The ETAS Experiment Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Validation and Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Measuring and Calibrating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Experimenting with Different Targets. . . . . . . . . . . . . . . . . . . . . . 114
Rapid Prototyping Experiment with the ETAS Experiment
Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Bypass Experiment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Fullpass Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
X-Pass Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Virtual Prototyping Experiments with the ETAS Experiment
Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Modules and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Description of the C Code Interface. . . . . . . . . . . . . . . . . . . . . . . 123
Description of Semantic Information . . . . . . . . . . . . . . . . . . . . . . 124
Model Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Module Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Creation of SCOOP-IX and Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
INTECRIO V4.6 - User’s Guide 5
6
Contents ETAS
Integrating GT-Power/GT-SUITE Models in INTECRIO . . . . . . . . . . . . . . . . . 140
Copying Example Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Handling Multiple GT-SUITE Installations . . . . . . . . . . . . . . . . . . . 141
ATLAB /Simulink Environment . . . . . . . . . . . . . . . . 142
Checking the Simulink/GT-SUITE Model. . . . . . . . . . . . . . . . . . . . 143
Building in INTECRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Preparation for Experiment with INCA or INTECRIO . . . . . . . . . . . 147
ETK Bypass Concept Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Classical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
With Distab17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Bypass Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Bypass Calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Bypass Output Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Message Copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Service Processes for the SBB Implemented as Service
Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Controlling the ECU Behavior from INTECRIO . . . . . . . . . . . . . . . 156
OS Configuration for Service-Based Bypass V3. . . . . . . . . . . . . . . 156
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Classical ECU Function Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Bypass of an Entire ECU Functionality . . . . . . . . . . . . . . . . . . . . . 158
Read and Write Actions of the Same Service Point in Different
Rasters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
ECU-Synchronous Write-Back . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Working with the INCA Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
INTECRIO V4.6 - User’s Guide
ETAS Introduction
1 Introduction
The INTECRIO manual supports the reader in becoming acquainted with INTEC-
RIO.
Chapter 2 "Understanding INTECRIO" presents the concepts that are important
for working with INTECRIO. Chapter 3 "INTECRIO and AUTOSAR" describes how
INTECRIO supports AUTOSAR. Chapter 4 "The INTECRIO Components"
describes the different components of INTECRIO, their tasks and methods of operation. Operating the components is explained in the online help.
Chapter 5 "SCOOP and SCOOP-IX" describes the SCOOP concept for the
description, management and exchange of C code interfaces and the interface describing language SCOOP-IX.
Chapter 6 "Modeling Hints" describes how the behavioral modeling tools are
used in conjunction with INTECRIO and provides an overview of the modeling philosophy of INTECRIO.
Chapter 7 "Bypass Concept" contains information on service-based and hook-
based bypass, chapter 8 "Glossary" contains lists of the most important abbrevi-
ations and terms, and chapter 9 "Appendix: The INCA Connector" briefly intro-
duces the INCA connector.
1.1
Safety Advice
Please adhere to the Product Liability Disclaimer (ETAS Safety Advice) and to the following safety instructions to avoid injury to yourself and others as well as damage to the device.
1.1.1
Correct Use
ETAS GmbH cannot be made liable for damage which is caused by incorrect use and not adhering to the safety instructions.
1.1.2
Labeling of Safety Instructions
The safety instructions contained in this manual are shown with the standard danger symbol shown below:
The following safety instructions are used. They provide extremely important information. Read this information carefully.
WARNING
Indicates a possible medium-risk danger which could lead to serious or even fatal injuries if not avoided.
INTECRIO V4.6 - User’s Guide 7
8
Introduction ETAS
CAUTION
Indicates a low-risk danger which could result in minor or less serious injury or damage if not avoided.
NOTICE
Indicates behavior which could result in damage to property.
1.1.3
Demands on the Technical State of the Product
The following special requirements are made to ensure safe operation:
• Take all information on environmental conditions into consideration before setup and operation (see the documentation of your computer, hardware, etc.).
WARNING
Wrongly initialized NVRAM variables can lead to unpredictable behavior of a vehicle or a test bench, and thus to safety-critical situations.
INTECRIO systems that use the NVRAM possibilities of the experimental targets expect a user-defined initialization that checks whether all NV variables are valid for the current project, both individually and in combination with other
NV variables. If this is not the case, all NV variables have to be initialized with their (reasonable) default values.
Due to the NVRAM saving concept, this is absolutely necessary when projects are used in environments where any harm to people and equipment can happen when unsuitable initialization values are used (e.g. in-vehicle-use or at test benches).
Further safety advice is given in section 7.5 "Safety Considerations" on page 153.
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
2 Understanding INTECRIO
Today, developers of electronic control units often face the problem that the control algorithms are developed for an embedded control software without the availability of any target hardware. The algorithms are created using behavioral modeling tools such as ASCET or M ATLAB® /Simulink
®
– i.e. with tools that allow for generating code based on the models. To overcome the lack of target hardware, virtual prototyping or a rapid prototyping hardware system, such as the
ES1000, ES900 and RTPRO-PC systems of ETAS, is used.
INTECRIO is an ETAS product family that supports developers in their daily task of developing embedded control software by providing a uniform software platform for virtual prototyping and rapid prototyping applications.
INTECRIO integrates code from different behavioral modeling tools (BMTs) in a complete virtual prototyping or rapid prototyping system, enables configuring the prototype and a hardware system for rapid prototyping, and allows the creation of executable code. Finally, the ETAS Experiment Environment allows for performing the virtual prototyping or rapid prototyping experiment. (In this context, performance means the process of the experiment under real-time conditions and the possibility of measuring and calibrating values during the experiment.)
ASCET-MD
ASCET-RP INTECRIO-ASC
M ATLAB
® /Simulink ®
Real-Time
Workshop ®
RTW
Embedded
Coder TM
M ATLAB
®
Coder TM
Simulink ®
Coder TM
Embedded
Coder TM
AUTOSAR
BMT
User
Code
Software components (C code, interface description, ...)
INTECRIO
Integration platform, BMT connectivity, Target connectivity
Experiment Environment
ES1000
ES910
RTPRO-PC PC (VP)
Fig. 2-1 INTECRIO – Overview
Before discussing the content details of INTECRIO in more detail, a few notes are necessary about electronic control unit development in general, about virtual prototyping and about the position of INTECRIO in the development cycle.
INTECRIO V4.6 - User’s Guide 9
10
Understanding INTECRIO ETAS
2.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.
2.1.1
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. 2-2; the figure is based on the V model). This short-
ens the total development time.
Development of electronic systems
Electronic control unit software development
Electronic control unit hardware development
Partitioning
...
Integration
Setpoint encoder and sensor development
Actuator development
Fig. 2-2 Overview of the development of electronic systems
INTECRIO V4.6 - User’s Guide
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 decades (see
Number
Number of functions per vehicle
ECUs per vehicle
Number of functions per electronic control unit
2000 Time 1970 1980 1990
Fig. 2-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.6 - User’s Guide 11
12
Understanding INTECRIO ETAS
As soon as a critical driving situation is discovered, the ESP system requests a reduction in engine torque from the engine control. This request is generally transferred via the CAN bus. As soon as the engine torque is reduced, the car can stabilize itself and the torque can subsequently be increased again. If the vehicle does not stabilize itself, the engine torque must be further reduced.
The following components are involved in the control algorithm: The ESP must detect the necessity for reducing the engine torque. It must send the CAN message and wait for a free position on the CAN bus. Depending on the load on the
CAN bus and the configuration of the communication, this may take some time.
Next, the engine control unit must process the request for a torque reduction.
The engine control unit also has other tasks (namely the engine control) that are very time-critical. As soon as it finds some time to reduce the torque, it will do so.
The sum of all these waiting times provides an imperfect control behavior which the driver may even notice (which is extremely undesirable).
This example underscores the fact that the electronics in the vehicle is becoming more and more complex. On the other hand, the electronics plays an important role for the success of a vehicle since 90% of all innovations in today's vehicles are based on electronics. For this reason, car manufacturers and suppliers alike are very much interested in increasing the quality and functionality of their vehicles.
2.1.2
Complexity Through Distributed Development
An additional contribution to the complexity of the electronic control unit development consists of the fact that the development is often formed by a strong division of labor between car manufacturers and suppliers. While the user requirements to be considered on a function of the vehicle to be developed are generally defined by the car manufacturer, the implementation of the functions through electronic systems is often carried out by suppliers. However, the coordination and acceptance of the implemented functions in the vehicle is generally the responsibility of the car manufacturer.
An indispensable prerequisite for a successful development with such a division of labor is a precise definition of the interfaces between car manufacturer and
supplier. They can be clearly represented in the V model (Fig. 2-4). While the car
manufacturer carries the responsibility for the vehicle–on the left as well as the right branch of the V model–the suppliers are frequently in charge of the component level, at times even for the first integration steps.
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
These interfaces can be defined differently from case to case, but they must be defined exactly and completely in any case.
Car manufacturer
Supplier
Vehicle development
Subsystem development
Car manufacturer
Supplier
Drive train development
Chassis development
Bodywork development
Multimedia development
Fig. 2-4 Responsibilities of car manufacturers and suppliers. The interfaces entered (dot-dash-lines) are examples.
The AUTOSAR partnership develops a standardization of basic system and inter-
face functions. INTECRIO V4.6 supports AUTOSAR; see chapter 3 for more infor-
mation.
2.1.3
Possible Steps
One could say now that the best way for a cost reduction consists of first defining the functionality that a vehicle must have, and then to determine which hardware is required for the system to run.
However, this would mean to redevelop the complete vehicle functionality at once, which would involve significant effort and even risks. Therefore, it would be more obvious to first describe today's electronic system and to control the complexity it contains. INTECRIO was developed for this reason. As soon as it is under control, optimization is the next step.
Additional information can be found in
• J. Schäuffele, Dr. T. Zurawka: "Automotive Software Engineering – Principles, Processes, Methods, and Tools".
2.2
Description of Electronic Systems
A complete electronic control unit description requires a description of the hardware as well as the software. As mentioned above, today's software can no longer be viewed only as a collection of different software components that run on independent electronic control units. Frequently, a complete control algorithm is already distributed across several electronic control units and, therefore, must be viewed and described as a whole, without orientation to the special electronic control unit.
INTECRIO V4.6 - User’s Guide 13
14
Understanding INTECRIO ETAS
Since networks are not yet supported in INTECRIO V4.6, the focus of this section is on the description of an individual electronic control unit.
2.2.1
Design and Operating Method of Electronic Systems
Design and operating method of the electronic systems of the vehicle are explained in detail using the electrohydraulic braking system as an example.
Environment
Other vehicles
Tool
(e.g. diagnostic tester)
Driver
Steering angle sensor
Wheel speed sensor
Bus
Electronic control units
Wheel brake
(actuator)
Hydro unit
Vehicle
Wheel brake
(actuator)
Brake pedal unit
(setpoint encoder)
Fig. 2-5 Design of the electrohydraulic brake (in Konventionelle und elektronische Bremssysteme , Robert Bosch GmbH (ed.), Stuttgart, 2002)
Fig. 2-5 shows the design of the electrohydraulic braking system (Sensotronic
Brake Control, SBC) from Bosch. The sensotronic brake control combines the functions of the power brake unit, anti-lock braking system (ABS) and ESP.
The mechanical activation of the brake pedal by the driver is sensed in the brake pedal unit and electrically transferred to the electronic control unit. This electronic control unit uses required values and different sensor signals, such as the steering angle signal or the wheel speed signals, to calculate output quantities which, in turn, are electrically transferred to the hydro unit where they are converted into controlled variables for the wheel brakes through pressure modulation. The handling of the vehicle, the so-called route (or controlled system) is influenced via the wheel brakes. For this reason, the wheel brakes are also referred to as actuators .
The electronic control unit can communicate with other electronic control units of the vehicle via a bus, such as CAN.
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
The system design illustrated by using the sensotronic brake control as an exam-
ple (see Fig. 2-6) is typical for all electronic control/closed-loop control and trac-
ing systems of the vehicle. In general, the following components of the vehicle can be distinguished: setpoint encoder , sensors , actuators, electronic control units for control/closed-loop control or tracing and route. The electronic control unit are linked by a network to allow for an exchange of data.
Driver Environment
Setpoint encoder
Vehicle
Control/closedloop control monitoring
Actuators Plant Sensors
Fig. 2-6 Schematic representation of control/closed-loop control and tracing systems
The driver (possibly also other passengers) and the environment (including other vehicles or electronic systems such as diagnostic tools in the environment of the vehicle) can affect the behavior of the vehicle and are components of the higherlevel system vehicle-driver-environment.
By itself, an electronic control unit is merely a means to an end. Only a complete electronic system consisting of electronic control units, setpoint encoders, sensors and actuators affects or monitors the route, thereby meeting the use expectations.
2.2.2
Architecture and Description of Electronic Systems
To describe an electronic system, a physical architecture that encompasses the electronic control units and networking of the vehicle as well as the distribution of the software to the existing hardware is required. Requirements such as the available space for the installation of electronic control units, required redundancies for safety-critical component, etc., enter into the physical architecture.
On the other hand, one needs a logical architecture that represents the functionality of the software, which ideally starts with a layout for the complete system that is subsequently broken down into functions, modules and individual classes.
In connection with AUTOSAR, AUTOSAR software components (SWC) take the place of modules and classes.
Naturally, the connection between both architectures, which distributes the functionality to the hardware, cannot be missing.
INTECRIO V4.6 - User’s Guide 15
Understanding INTECRIO ETAS
Fig. 2-7 shows both architectures; the areas in which INTECRIO is being used are
circled.
Logical architecture Physical architecture
On-board network
Software system
Subsystems, buses
Function
Electronic control unit
CPU
INTECRIO
Module
Tasks
Task
Task
Task
Task
Class
Other classes
Processes
Function calls
Process
Method
Process
Method
Process
Method
Method
Process
Fig. 2-7 Architecture of an electronic control unit description
A detailed description from the perspective of INTECRIO is presented below.
16 INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
Fig. 2-8 shows an overview of the different components of an electronic control
unit description.
Module A / SWC A
Module B / SWC B Module C / SWC C
Crossbar / AUTOSAR-RTE
Communication driver / Basic software I/O driver
(HAL) / complex device drivers
OSEK operating system
....
[…] Target-specific […] Generic (all targets) I/O interface
Fig. 2-8 Electronic control unit description: Overview (INTECRIO view)
Application Software
The application software (or functional software) contains the signal flow-driven control algorithm. This is a generic description that does not change its behavior
(based on requirements and specifications). The software consists of individual modules or AUTOSAR software components and module/SWC groups or func-
tions (see Fig. 2-9 and the left side of Fig. 2-7).
Module/SWC A
Module/SWC B Module/SWC C
Module/
SWC A
Module/
SWC B
Module/
SWC C
Crossbar / AUTOASR-RTE
Communication driver
OSEK operating system
I/O driver
(hardware abstraction layer)
....
Fig. 2-9 Functional software: Details
Signal sinks
BMT view
Activation interface
Calculation algorithm
Signal sources
Data
INTECRIO V4.6 - User’s Guide 17
18
Understanding INTECRIO ETAS
The overview in Fig. 2-2 shows the development of the electronic control unit
software as a single development phase; however, section 2.1.2, Fig. 2-4 already
showed that this phase is divided again into other phases. This figure is still too rough, though; even in the development of a specific functionality, it is possible that the individual modules, SWC or functions are developed by different suppliers using different tools.
Modules and AUTOSAR software components are principally designed the same way from the INTECRIO perspective and feature the following interfaces:
• Signal sinks (inputs or clients and receivers),
• Signal sources (outputs or server and sender),
• Activation interfaces (processes or runnable entities (RE); graphically not shown).
Sink 1 Source 1
Sink 2
...
Source 2
...
Module 1
Signal flow connection
Sink 1 Source 1
Sink 2
...
Source 2
...
Module 2
Receiver
Client
Mode
SWC A
Sender
Server
Fig. 2-10 Module/SWC: Schematic design (external view) and connection
Modules and AUTOSAR software components are also identical from an internal design. In addition to the interfaces listed, the internal view contains the following components:
• Calculation algorithm or functionality,
• Data of variables, constants and parameters.
Sink 1 Source 1
Sink 2 Source 2
...
Module 1
...
Activation interface
Signal sinks
(inputs)
Calculation algorithm
Signal sources
(outputs)
Sink 1 Source 1
Sink 2 Source 2
...
Module 2
...
Internal view
Fig. 2-11 Modules: schematic internal view
Data (variables/ constants/parameters)
Module 1
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
Fig. 2-12 shows a simple ASCET example for the internal view of a module.
Activation interface
Signal sinks
Calculation algorithm
Signal sources
Internal view
Data
Fig. 2-12 Module: ASCET example
The activation interfaces correspond to the ASCET processes, signal sinks and sources correspond to the receive and send messages in ASCET. Variables, parameters and constants are represented by ASCET objects of the same name.
Fig. 2-13 shows the same example for M
ATLAB /Simulink.
Simulink model
Activation interface
Signal sinks
Calculation algorithm
Signal sources
Internal view
Data
Fig. 2-13 Module: Simulink ® example
For information to be exchanged between modules/SWC or functions and to create a functioning overall system, the objects must be interconnected, i.e. integrated. The calculation algorithms of the individual modules/SWC, i.e. their functionality, do not play a role for integration. The modules are handled as "black boxes" with and
Source 1 = f
1
(sink 1, sink 2, ...)
Source 2 = f
2
(sink 1, sink 2, ...)
INTECRIO V4.6 - User’s Guide 19
20
Understanding INTECRIO ETAS
This integration is the responsibility of INTECRIO. To be able to fulfil this task, the model supplied by a BMT is dismantled for working with INTECRIO into descrip-
tion files for the interfaces and data as well as into C code (see Fig. 2-14). These
files form a reusable software component; they can be processed by INTECRIO.
Interface description file
(SCOOP-IX)
Activation interface
C code Signal sinks
(inputs)
Calculation algorithm
Signal sources
(outputs)
Internal view
Data (variables/ constants/parameters) Data description file
(ASAM-2MC)
Fig. 2-14 Internal view and component view of a module (dashed: descriptions; solid: implementations)
Platform Software: Hardware Systems
On the other side are the hardware systems that are affected by cost factors and the different variants of a vehicle. The hardware is a network of electronic control units that form a complete hardware topology. The latter must describe all aspects of the hardware system that is available to the software. The hardware system is also a generic system whose behavior or properties do not change.
With virtual prototyping, a model of driver, vehicle and environment is used instead of real hardware and environment.
Connecting Hardware and Software
Finally, both systems must be connected with each other. To build a prototype
(or an actual vehicle project), the description of the software system must be linked with the description of the hardware system. This linking forms a concrete application. Of course, this requires some "adhesive" to connect the generic software description and the generic hardware description.
INTECRIO is the tool that provides this "adhesive" in the form of a project configurator and connects the hardware description with the description of the application software. Here, the focus is on the hardware description – it is configured in INTECRIO while the components that form the application software are provided by special behavioral modeling tools.
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
Fig. 2-15 shows the representation of an electronic control unit description and
the tasks taken on by the various INTECRIO components.
Module A / SWC A
Module B /
SWC B
Module C /SWC C
Crossbar / AUTOSAR RTE
Communication driver / Basic software
OSEK operating system
I/O driver
(HAL) / complex device drivers
....
BMTs
M ATLAB /Simulink
ASCET-MD
ASCET-RP
INTECRIO-ASC
RTW / Simulink Coder
Embedded Coder
INTECRIO
BMT connectivity
INTECRIO
Integration platform
INTECRIO target connectivity
ES1000
ES900 PC
(VP / RP)
Fig. 2-15 System project (electronic control unit description) and INTECRIO components
2.3
Virtual Prototyping
Virtual prototyping means that function developers can create virtual prototypes of automotive electronic systems and test them on the PC. A virtual prototype of this kind comprises:
• Automotive embedded software
– application software (functions for control and monitoring)
– platform software (I/O drivers, operating system, etc.)
• Plant model
– driver
– vehicle
– environment
Virtual prototyping enables collaboration in very early development phases between function developers on one hand and system developers and simulation experts on the other hand. Without virtual prototyping, these domains often do not come into contact until very late in the process, e.g., during HiL (Hardwarein-the-Loop) testing. With virtual prototyping, developers can use system models
(such as chassis or engine models) in early stages of the process as well, and thus validate their functions through Model-in-the-Loop (MiL) technology. Access to system knowledge (and the corresponding models) early in the process creates synergies between function development and system development in an ideal way and fosters a more efficient development process.
INTECRIO V4.6 - User’s Guide 21
22
Understanding INTECRIO ETAS
2.3.1
Target-Close Prototyping
In INTECRIO, models can be created using a variety of different tools or a combination thereof (M ATLAB /Simulink, ASCET, C code). With the PC connectivity provided by INTECRIO-VP, developers can now work within their familiar tool environment and execute their virtual prototype directly at their desks on a standard Windows PC. Already in the function design phase, developers can thus validate the functional architecture and verify the electronic architecture against the plant model. Moreover, they can do all of this under target-close conditions.
To put it plainly:
INTECRIO Integration Platform
+ Function Model
+ Plant Model
+ Standard PC
+ RTA Virtual OSEK
_____________________________________
= Virtual Prototyping with INTECRIO
By supporting RTA-OSEK for PC, a complete OSEK operating system for the PC,
INTECRIO-VP offers conditions that later exist on the vehicle ECU. These include task and process oriented scheduling and buffered message communication between individual OS processes. At the same time, INTECRIO-VP takes advantage of the flexibility and short turn-around times of testing on the PC, which offers ample room for experimentation due to fewer constraints in terms of timing, memory consumption, etc. than exist on the target ECU.
2.3.2
Advantages of Virtual Prototyping
Virtual prototyping offers new opportunities for early phases of vehicle development, such as pre-calibration in the office, detailed analysis of function behavior, and control over the execution speed of a prototype, as the following three examples illustrate.
1. Saving time and money through pre-calibration
With virtual prototyping, developers can move some of the necessary development steps from the test bench to the lab or to their desks and validate, optimize, and pre-calibrate functions against a plant model right there. In addition, a virtual testing environment on the PC also offers developers the advantage of being able to minimize the execution time of experiments (given the computational power and the complexity of the model) and thus test a larger amount of functions or data variants in a
shorter amount of time (Fig. 2-16 bottom).
2. Detailed analysis using highly elaborate simulation models
The option of validating a new function based on elaborate plant simulations allows developers to conduct a detailed analysis of its behavior. This possibility is particularly valuable when an in-depth analysis is not possible in the real-world environment.
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
3. Slow-motion and fast forward
With INTECRIO-VP, users can influence simulation time by defining a scaling factor and adjusting it while the simulation is running. Scaling factors
< 1 allow users to accelerate the simulation, while scaling factors > 1
result in a "slow motion" effect (Fig. 2-16, top). With that, users can, e.g.,
run the relevant parts of a simulation in slow motion.
Virtual Prototyping using scaled simulation time (Slow Motion)
0 10 20
0 10 20 30 40
Virtual Prototyping using adaptive simulation time
Simulation time [ms]
Actual time
(PC clock) [ms]
0 10 20 30 40 50
Simulation time [ms]
Actual time
(PC clock) [ms]
0 10 20 30 40
OS
Scheduling
Simulation of SW function model
Simulation of environment model
Windows latency
Fig. 2-16 Top: During simulation in scaled time, slow motion timing or fast forward timing can be achieved (within the limits of model complexity and computational power).
Bottom: In a simulation with adaptive time, complex models can be executed at the fastest possible speed (i.e., the least possible computation time).
2.3.3
Virtual Prototyping and Rapid Prototyping
In INTECRIO, the function model is strictly separated from OS configuration, hardware configuration, and instrumentation. Given this separation, fewer model variants have to be created, and the optimum re-use of software prototypes, experiments, and data sets can be ensured across teams, target platforms, and development phases. Being able to re-use virtual prototyping models in rapid prototyping will lead to considerable synergies.
INTECRIO V4.6 - User’s Guide 23
Understanding INTECRIO ETAS
To summarize the advantages of using both virtual and rapid prototyping:
Virtual Prototyping enables developers to validate functions and software
Rapid Prototyping enables developers to validate and verify functions and software
– in the context of a simulated world at their desks
– in the context of the real world, i.e. using real world interfaces and signals
– with pre-calibration options
– without any dedicated hardware
– on particularly designed hardware systems
– not restricted by real-time requirements
– in real time (e.g., through a bypass experiment)
Virtual prototyping thus complements the prototyping options available in
INTECRIO to date. With INTECRIO-VP, vehicle developers are able to test new functions against plant simulations in early phases of development, which will contribute to a more efficient development process.
2.4
INTECRIO in the Development Process
Electronic control unit software is generally developed according to the V model.
In the process, smaller V cycles are typically passed through on every level.
Fig. 2-17 shows the V model; the areas in which INTECRIO is used are marked.
Function development
Virtual
Proto-
typing
Rapid
Prototyping
Test
Measurement and Application
Software development
24
Fig. 2-17 V cycle and INTECRIO
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
In other words: INTECRIO allows the user a simple and quick integration of software components from different manufacturers and different BMTs as well as the verification and validation of the software (in whole or in part) in virtual or rapid prototyping. New experimenting options allow for quick and complete validation and verification of software modules.
Validation is the process for evaluating a system or a component with the purpose of determining whether the application purpose or the user expectations are met. Therefore, the validation is the check whether the specification meets the user requirements, whether the user acceptance is reached by a function after all.
Verification is the process for evaluating a system or a component with the purpose of determining whether the results of a given development phase correspond to the specifications for this phase. Therefore, software verification is the check whether an implementation of the specification specified for the respective development step is sufficient.
A clear separation of validation and verification is often not possible when classical development, integration and quality assurance methods for software are used. Therefore, a significant advantage of the use of INTECRIO as rapid prototyping tool consists of the fact that it allows for an early and electronic control unit-independent function validation with an experimental system in the vehicle.
2.5
The INTECRIO Working Environment
The design of INTECRIO is modular. The graphical framework forms the working interface in which the various INTECRIO components are integrated.
Toolbar
INTECRIO Vx.y
File Edit View ...
Title Bar Menu bar
WS browser
(tree view of workspace)
Display window for the different components
Scripting Window
Messages of the current component
Bottom pane
Fig. 2-18 INTECRIO – Scheme of the interface
The graphical interface of INTECRIO is always designed in the same way. Below a menu bar and a toolbar, he interface of the currently used configurator (OS, project or hardware configurator) with the respective processing options is displayed in the top right field. The two lower fields are used for scripting (see online help for details) and as display for messages of the currently used configurator. The bottom pane contains various status information.
INTECRIO V4.6 - User’s Guide 25
26
Understanding INTECRIO ETAS
The top left field, the WS browser, displays the current workspace in a tree structure. The workspace contains all the components of an electronic control unit description in four predetermined main folders for hardware systems, software systems, environment systems (virtual prototyping) and system projects.The
entire electronic control unit description is processed from here.
Workspace
Hardware
Hardware Systems
Software
Modules (contains modules and SWC)
Functions
Software Systems
Environment (contains environment software)
Modules
Functions
Environment Systems
Systems (contains system projects)
Fig. 2-19 Folder structure: workspace
Hardware systems: A hardware system is used for the configuration of the platform software. It contains the complete description of a hardware topology, consisting of the descriptions of the associated ECUs (rapid and virtual prototyping targets) and – in later INTECRIO-versions – networks as well as the descriptions of the interfaces (bus systems) between the devices.
The components of the hardware systems are stored in the
Hardware
folder.
Workspace
Hardware
Hardware Systems
ECU 1 (Experimental Target)
Controller 1
Hardware I/O
...
Software
Environment
Systems
Fig. 2-20 Folder structure: hardware systems
Software systems and environment systems: A software system contains the application software, i.e. the generic parts of the control algorithm. For one thing, these are the modules and AUTOSAR software components (SWC) that contain the functionality. In addition, functions and connections between modules, SWC and functions are part of the software system. In INTECRIO V4.6, the execution sequence is automatically determined based on the overall configuration.
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
An environment system contains the plant model for virtual prototyping, i.e. the model of driver, vehicle, and environment. An environment system is built like a software system.
The components of the software systems are stored in the
Software
folder and the corresponding subfolders. The components of the environment systems are stored in the
Environment
folder and the corresponding subfolders.
Workspace Workspace
Hardware
Software
Software
Modules
Module A
Signal sources
Environment
Modules
Module D
Signal sinks
Signal sources/sinks
SWC B
(more modules/SWC)
(more modules/SWC)
Functions
Functions
Function 1
Module A (by reference)
Function 2
Modules + SWC (by reference)
Module C (by reference)
(more functions)
(more functions)
Environment Systems
Environment system
Software Systems
Functions/modules/SWC (by reference)
Software system
Function 2 (by reference)
Module E (by reference)
Systems
(more functios/modules/SWC by reference)
(more environment systems)
(more software systems)
Hardware
Environment
Systems
Fig. 2-21 Folder structure: software systems and environment systems
System projects: A system project is a complete electronic control unit description. It combines a hardware system, a software system and an environment system into an overall project. The mapping of the signals provided by the hardware onto the corresponding software signals and the configuration of the operating system (OS configuration) are also a part of the system project.
INTECRIO V4.6 - User’s Guide 27
28
Understanding INTECRIO ETAS
The system project are stored in the
Systems
folder.
Workspace
Hardware
Software
Environment
Systems
System Project 1
Hardware System (∗)
Controller 1 (∗)
Board 1 (∗)
Device 1 (∗)
Signal Group 1 (∗)
Signals (∗)
(other Signal Groups (∗))
(other Boards (∗))
OS Configuration
Software System (∗)
Functions ( ∗ )
Modules / SWC ( ∗ )
Environment System ( ∗)
Functions ( ∗ )
Modules / SWC ( ∗ )
(other System Projects)
Fig. 2-22 Folder structure: system project (objects marked with * are referenced)
Software systems, hardware systems, environment systems (for virtual prototyping) and system projects are described in detail in the following sections.
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
2.5.1
Software Systems
This section provides a detailed description of software systems. Fig. 2-23 shows
the content of a software system. The lines symbolize inclusion relationships; dashed objects in the background are optional (if available, they contain the same objects as the corresponding foreground object).
Software System
Function (optional)
Signal mapping
Input signals
Output signals
Processes /
RE
Fig. 2-23 The software system
Modules and AUTOSAR Software Components
The modules and AUTOSAR software components (SWC) in INTECRIO contain the descriptions of the software modules that were imported in the system.
These can be user-defined ASCET modules, Simulink models or AUTOSAR software components, but also test functions or complex stimulus generators in
C code or plant models (for "software in the loop" applications). The descrip-
tions are based on SCOOP-IX descriptions (see chapter 5 "SCOOP and SCOOP-
IX") or XML for AUTOSAR software components.
as well as the activation interfaces (processes, or runnable entities for SWC) of
the user-defined modules and SWC (interface description file in Fig. 2-14). The
functionality of the software modules and SWC that was created with different
BMTs is not of importance here.
In INTECRIO, hardware I/O ports are also considered as modules with signal sources and sinks.
The signal mapping , i.e. the connections between the corresponding inputs and outputs that are required for information exchange, must be performed explicitly. There are no implicit connections, such as via same name.
INTECRIO V4.6 - User’s Guide 29
30
Understanding INTECRIO ETAS
Fig. 2-24 shows the simple connections: A source is connected with a sink (A) or
with several sinks (B); source and sinks have the same timing.
A
Sink 1 Source 1
Sink 2 Source 2
B
Sink 1 Source 1
Sink 2 Source 2
Sink 1 Source 1
Sink 2 Source 2
Fig. 2-24 Connections: A source, one or several sinks, same timing
In addition, other connections are possible:
• A source is connected with various sinks; source and sink(s) have a different timing.
Sink
Source 1 Buffer
Sink
Fig. 2-25 Connection: One source, several sinks, different timing
The data of the source are buffered and then forwarded to the sink(s).
• Two sources are connected with a sink ( only for rapid prototyping).
Source
Version 1
Sink
Source
Version 2
Fig. 2-26 Connection: several sources, one sink
There are two alternatives: On the one hand, switching between the two
sources (see Fig. 2-26) during the prototyping phase is accomplished by
using a crossbar manager (see section 2.5.5). On the other hand, the con-
nection can be permanently coded during the software development phase.
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
Functions
Modules and SWC can be inserted in a software system either directly or – to provide a better overview or for a simple reuse – grouped in functions . These functions are classification objects without separate functionality (similar to the hierarchies in ASCET block diagrams).
A function consists of the following components:
• One or several modules or SWC,
• Connections between inputs and outputs of the contained modules or
SWC,
• The function interface (inputs, outputs and activation interfaces).
The inputs and outputs of a function cannot have their own data or implementations. Outputs can be connected with one or several sinks of the modules/ functions contained in the function, inputs with exactly one source of a module/ function. With SWC, the output type determines whether the output can be
connected to one or more inputs (see "Ports and Interfaces" on page 46).
It is also possible to automatically create the inputs and outputs of the function.
However, only the module/SWC inputs that are not yet connected can be taken into account. Outputs take into account either all sources of the modules/SWC contained in the function or only those that are not yet connected.
Module 1
Sink
Source
Module 2
Sink
Source
SWC C
Receiver
Sender
Receiver
Function
Fig. 2-27 Example for a function
Modules cannot be instantiated in INTECRIO. If a module is inserted into a function more than once (either directly or as part of an inserted function), an error message is issued during code generation.
INTECRIO V4.6 - User’s Guide 31
32
Understanding INTECRIO ETAS
Software Systems
A complete software system can be assembled from any number of functions and individual modules or SWC.
Module 1
Sink
Source
Module 2
Sink
Source
Module 4
Sink
Source
Module 6
Sink
Source
SWC C
Receiver
Sender
Receiver
Function A
Module 3
Sink
Source
Function B
Module 5
Sink
Sink Source
Sink
Fig. 2-28 Example for a software system
Since modules and SWC cannot be instantiated, each module/SWC may appear only once, regardless of whether it is a part of a function or not. Except for the creation of functions, an automatic check does not take place until the system
project is created (see section 2.5.4).
Tip
Make sure that no module/SWC already included in a function is individually inserted into the software system. Otherwise, the following error message is issued during code generation:
Build preparation error: Multiple instances of same module in software system
2.5.2
Environment Systems
Environment systems are used to model the plant model for virtual prototyping
(see section 2.3). They are built out of modules, SWC and functions, the same
way as software systems.
A module, SWC or function can, within one workspace, be used either for a software system or an environment system. It is not possible to include modules,
SWC or functions imported/created for a software system (
Software\Modules
and
Software\Functions
folders) in an environment system, and vice versa.
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
2.5.3
Hardware Systems
Fig. 2-29 shows the content of a hardware system (the lines symbolize inclusion
relationships). In the framework of the hardware system, the existing hardware and the interfaces between the individual units (e.g. ETK, CAN) are described.
Hardware System
ECU description
CPU description
I/O interface
Input signals Output signals
Fig. 2-29 The hardware system.
The ECU description is the description of an individual controller hardware that is usually installed inside a housing. (Despite different boards or interfaces, the experimental targets are considered electronic control units.)
This includes descriptions of all processors of the electronic control unit and the connections between the processors.
The CPU description is the description of an individual processor with all the relevant details. This includes
• Characteristics of the processor (type, brand, etc.),
• Processor speed,
• Memory layout,
• Additional processor-specific configurations.
The I/O interface describes the interface between the input/output signals and the processor.
The input and output signals are linked with a specific processor. They are used to configure the inputs and outputs of the hardware (sensors and actuators) and to establish the connection to the corresponding processor signals.
INTECRIO V4.6 - User’s Guide 33
Understanding INTECRIO ETAS
2.5.4
System Projects
The system project combines a hardware system, a software system and an environment system (optional; for virtual prototyping) into an overall project. A check is performed whether each module occurs only once in the overall project; if a module occurs multiple times, an error message is issued.
In the system project, the signals provided by the hardware are mapped onto the signals available in the software and the processing sequence of the processes is defined in the framework of the operating system configuration.
Fig. 2-30 shows a system project. Dashed objects in the background are
optional; if available, they contain the same objects as the corresponding foreground object.
34 INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
Signal mapping
Function
Module /
SWC
Processes /
RE
Output signals
Input signals
Signal mapping
Function
Module /
SWC
Processes /
RE
Output signals
Input signals
Output signals
ECU description
CPU description
I/O interface
Input signals
Function sd
(referende)
ECU description sd
(reference)
Output signals
Input signals
Output signals
Input signals
OS configuration
CPU description sd
(reference)
Fig. 2-30 System project
Software, environment, and hardware systems are described in sections 2.5.1,
The signal mapping references the functions/modules/SWC of the software or environment and the ECU description with the respective inputs and outputs.
The mapping is performed here. Since functions/modules/SWC and ECU description are referenced, changes to the software or hardware system immediately impact the signal mapping.
INTECRIO V4.6 - User’s Guide 35
36
Understanding INTECRIO ETAS
The scheduling , i.e. the processing sequence of the tasks and processes/runnable entities, is defined in the configuration of the operating system, i.e. the OS configuration . In the OS configuration, tasks are created and configured, to which the processes (activation interfaces) of the system are subsequently assigned.
Task #1 Task #2
Process 1 Process 1
Sink 1
Sink 2
Source 1
Source 2
Sink 1
Sink 2
Source 1
Source 2
Sink 1
Sink 2
Process 1
Source 1
Source 2
Fig. 2-31 Assigning processes to tasks
2.5.5
Crossbar
The connections between modules, functions and hardware are managed and controlled by the Crossbar . When a system project contains at least one SWC, an
AUTOSAR runtime environment (see section 3.2 on page 44) is used instead of
the Crossbar.
The Crossbar is a software component that is executed with the target (e.g.
ES1135). The task of the Crossbar consists of connecting any signal sources with any signal sinks. For this purpose, a signal source may be connected with several signal sinks, but a signal sink can be connected only with exactly one signal source.
The Crossbar can manage static and dynamic connections in interaction with the project configurator. Static connections cannot be changed during runtime; if you want a change, you must cancel the experiment, perform the change and recompile the project. Dynamic connections can be changed during runtime.
At runtime, the Crossbar receives the information about each connection
(source, sink, involved processes, variable type, ...). Value assignments by the
Crossbar are always performed before calling the "consuming" module. This
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO allows the Crossbar to trigger the necessary actions at runtime. The result are connections between signal sources and sinks that are represented as grey circles
Scheduling information
Crossbar
Source 0
Source 1
Source 2
Source n
Fig. 2-32 Crossbar – Overview
The patented Crossbar guarantees real-time security for the modules through carefully arranged copy actions. Required requantizations and data type conversions are automatically performed.
A simple assignment serves as an example: sink 1 = source 0
If the two sides of the assignment are quantized differently, the value of source 0
is requantized and then assigned to sink 1
. If both sides feature different data types, source 0
is converted to the data type of sink 1
.
INTECRIO V4.6 - User’s Guide 37
38
Understanding INTECRIO ETAS
2.6
Experimenting with INTECRIO
The executable prototype is created from the system project by using the project
integrator (see section 4.10 "The Project Integrator"). Such a prototype shows
the software functions in practical use – entirely with different goal directions and in a different appropriation.
Prototype of a control algorithm
Control algorithm
Software system
Prototyping hardware system
ES1000
Sink 1 Source 1
Sink 2 Source 2
Sink 1
Sink 2
Source 1
Source 2
Sink 1
Sink 2
Source 1
Source 2
ES900
PC
(RP / VP) External interfaces, e.g. CAN-DB
Fig. 2-33 Prototype for rapid or virtual prototyping experiment
By using the prototype, a rapid prototyping hardware and an experiment environment (e.g., the ETAS Experiment Environment), the experiment can be performed under real-time conditions (also automatically if needed). This experiment fulfils the following purposes:
• Validation of the control algorithm (in whole or in part)
• Verification of the software implementation
• Verification of the implementation information of the model magnitudes
In the experiment, values can be measured and calibrated in different measuring and calibration windows. The configuration of the measuring and calibration windows can be carried out either before or during the experiment. In a virtual prototyping experiment, the simulation speed can be adjusted at runtime, too.
Back animation, i.e. the display of the model values in the respective BMT and calibrating from within the BMT, is possible if the models were prepared accordingly.
INTECRIO V4.6 - User’s Guide
ETAS Understanding INTECRIO
Connections that were created as dynamic connections during the creation can be changed during the running experiment. This can be useful, for example, if the fixed-point code implementation of a model is to be compared with the physical model or different versions of a model.
Sink Source
Floating-point code /
Version 1
Hardware input
Hardware output
Sink Source
Fixed-point code /
Version 2
Fig. 2-34 Different models that can be connected with the hardware as an option
Additional modification options during the running experiment include
• Change of conversion formulas of simple I/O signals,
• Switching individual signal groups on/off,
• Switching events on/off,
The data gained during the experiment can be logged and analyzed under different points of view. The results can be documented automatically.
INTECRIO V4.6 - User’s Guide 39
40
INTECRIO and AUTOSAR ETAS
3 INTECRIO and AUTOSAR
This chapter describes how INTECRIO supports AUTOSAR. Section 3.1 overviews
the purpose of AUTOSAR, section 3.2 describes the AUTOSAR runtime environ-
ment (RTE), section 3.3 lists the AUTOSAR elements supported by INTECRIO.
This chapter contains no detailed introduction to AUTOSAR; corresponding documents can be found at the AUTOSAR website: http://www.autosar.org/
3.1
Overview
Today, special effort is needed when integrating software components from different suppliers in a vehicle project comprising networks, electronic control units
(ECUs), and dissimilar software architectures. While clearly limiting the reusability of automotive embedded software in different projects, this effort also calls for extra work in order to provide the required fully functional, tested, and qualified software.
By standardizing, inter alia, basic system functions and functional interfaces, the
AUTOSAR partnership aims to simplify the joint development of software for automotive electronics, reduce its costs and time-to-market, enhance its quality, and provide mechanisms required for the design of safety relevant systems.
To reach these goals, AUTOSAR defines an architecture for automotive embedded software. It provides for the easy reuse, exchange, scaling, and integration of those ECU-independent software components (SWCs) that implement the functions of the respective application.
The abstraction of the SWC environment is called the virtual function bus (VFB).
In each real AUTOSAR ECU, the VFB is mapped by a specific, ECU-dependent implementation of the platform software. The AUTOSAR platform software is split into two major areas of functionality: the runtime environment (RTE) and the basic software (BSW). The BSW provides communications, I/O, and other functionality that all software components are likely to require, e.g., diagnostics and error reporting, or non-volatile memory management.
INTECRIO V4.6 - User’s Guide
ETAS INTECRIO and AUTOSAR
3.1.1
RTA-RTE and RTA-OS
The runtime environment provides the interface between software components,
BSW modules, and operating systems (OS). Concerning the interconnection of
SWCs, the RTE acts like a telephone switchboard. This is similarly true of components that reside either on single ECUs or networked ECUs interconnected by vehicle buses.
SWC 1
AUTOSAR
Interface
SWC 2
AUTOSAR
Interface
SWC 3
AUTOSAR
Interface
...
SWC n
AUTOSAR
Interface
Virtual Function Bus (VFB)
ECU 1
SWC 1
AUTOSAR
Interface
SWC 3
AUTOSAR
Interface
Runtime Environment (RTE)
ECU 2
SWC 2
AUTOSAR
Interface
RTE
...
ECU m
SWC n
AUTOSAR
Interface
RTE
Basic Software (BSW) BSW BSW
Gateway
Vehicle Bus
Fig. 3-1 AUTOSAR software component (SWC) communications are represented by a virtual function bus (VFB) implemented through the use of the runtime environment (RTE) and basic software (BSW).
In AUTOSAR, the OS calls the runnable entities of the SWCs through the RTE.
RTE and OS are the key modules of the basic software with respect to controlling application software execution.
ETAS has been supplying the auto industry with automotive operating systems for more than a decade: ERCOS EK and now RTA-OSEK. The RTA-RTE AUTOSAR
Runtime Environment and RTA-OS AUTOSAR Operating System extend the RTA product portfolio with support for the key AUTOSAR software modules. RTA-
OSEK currently supports AUTOSAR OS Scalability Class 1.
Based on their AUTOSAR interfaces, basic software modules from third-party suppliers can be seamlessly integrated with RTA-RTE and RTA-OSEK.
INTECRIO V4.6 - User’s Guide 41
INTECRIO and AUTOSAR ETAS
3.1.2
Creating AUTOSAR Software Components (outside INTECRIO)
INTECRIO is not intended for the creation of AUTOSAR software components.
ASCET , however, if necessary in addition to an AUTOSAR authoring tool, which provides initial descriptions of the system architecture and AUTOSAR interfaces, allows defining and implementing the behavior of AUTOSAR-compliant vehicle functions.
Existing ASCET models can be easily adapted to AUTOSAR because many AUTO-
SAR concepts can be mapped to interface specifications in ASCET in a similar form. On the whole, it suffices to rework the interface of the respective application to make it AUTOSAR-compliant. As shown in practical demonstrations of adapting older models, the expenditure in terms of time is relatively minor, even with the ASCET version in current use.
ASCET V6.4 supports AUTOSAR SWC descriptions and the generation of AUTO-
SAR-compliant SWC production code according to AUTOSAR R3.0.* 1 , R3.1.* 2 and R4.0.* 3 .
3.1.3
Validating Software Components
The virtual function bus concept of AUTOSAR opens the road to virtual integration. Because the virtual function bus blurs the ECU borders, software components of different functions can be integrated in the design phase prior to having completed the final mapping to individual ECUs. This means that the interaction of software components integrated by an RTE can be easily tested on a PC running an AUTOSAR OS.
42
1. * = 2 or 4
2. * = 0, 2, 4 or 5
3. * = 2 or 3
INTECRIO V4.6 - User’s Guide
ETAS INTECRIO and AUTOSAR
INTECRIO
INTECRIO provides a powerful environment for prototyping and validating automotive electronic systems. Version V4.6 enables the integration of AUTOSAR
SWCs with legacy function modules (Fig. 3-2). INTECRIO thus provides for the
reuse of existing models and C code during the migration of ECU software to
AUTOSAR architectures.
INTECRIO INTECRIO
RTA-TRACE RTA-TRACE
ASCET
Model
Simulink
Model
...
C Code
Module
A
...
Rapid
Prototyping
Module
ASCET
Model
Crossbar RTE
Simulink
Model
...
SWC
AUTOSAR
Interface
B
AUTOSAR RTE
SWC 1
AUTOSAR
Interface
SWC 2
AUTOSAR
Interface
...
SWC n
AUTOSAR
Interface
C
ECU
Bypass
Vehicle Bus
...
AUTOSAR RTE
Step 1:
Integration of software components
Step 2:
Virtual prototyping on the PC
Step 3:
Rapid prototyping in real-world environment
Fig. 3-2 Integration (left) of software modules for virtual prototyping (middle) or rapid prototyping (right) with the AUTOSAR RTE.
AUTOSAR SWC can be combined with legacy functions (B) or tested as a pure AUTOSAR system (C).
By using plant models, Model-in-the-Loop experiments are realized on the PC.
INTECRIO V4.6 - User’s Guide 43
INTECRIO and AUTOSAR ETAS
44
INTECRIO V4.6 allows import of AUTOSAR SWC descriptions and the generation
of the RTE configuration according to several AUTOSAR versions (see Tab. 3-1).
AUTOSAR version Remarks
R3.0.0
not supported by ASCET not supported by ASCET R3.0.1
R3.0.2
R3.1.0
R3.1.2
R3.1.4
R4.0.2
R4.0.3
NVData interfaces and ModeSwitch interfaces are not supported by INTECRIO V4.6
Tab. 3-1 Supported AUTOSAR versions
INTECRIO V4.6 also provides the interpolation routines required for AUTOSAR
SWC descriptions generated by ASCET-SE.
With RTA-RTE 1
for the AUTOSAR releases mentioned in Tab. 3-1 and RTA-OSEK
V5.0 (targets ES900, RTPRO-PC and VP-PC) or ERCOS EK V4.3 (target ES1000),
INTECRIO V4.6 can create close-to-production AUTOSAR prototypes for PC and
ETAS rapid prototyping systems.
INTECRIO strictly separates the communications between software components from the prototyping hardware configuration. Thus, INTECRIO V4.6 is able to export the validated RTE configuration in the form of an XML file. An AUTOSAR
RTE generator, e.g., RTA-RTE, can use this information to create the RTE of an
AUTOSAR ECU.
3.2
What is a Runtime Environment?
The VFB provides the abstraction that allows components to be reusable. The runtime environment (RTE) provides the mechanisms required to make the VFB abstraction work at runtime. The RTE is, therefore, in the simplest case, an implementation of the VFB. However, the RTE must provide the necessary interfacing and infrastructure to allow software components to:
1. be implemented without reference to an ECU (the VFB model); and
2. be integrated with the ECU and the wider vehicle network once this is known (the Systems Integration model) without changing the application software itself.
More specifically, the RTE must
• Provide a communication infrastructure for software components.
This includes both communication between software components on the same ECU (intra-ECU) and communication between software components on different ECUs (inter-ECU).
1. RTA-RTE 3.1 can be used with AUTOSAR R3.1.4, R3.1.2, R3.1.0, R3.0.0, R3.0.1 and R3.0.2,
RTA-RTE 5.4 can be used with AUTOSAR R4.0.*.
INTECRIO V4.6 - User’s Guide
ETAS INTECRIO and AUTOSAR
• Arrange for real-time scheduling of software components.
This typically means that the runnable entities of the SWC are mapped, according to time constraints specified at design time, onto tasks provided by an operating system.
Application software components have no direct access to the basic software below the abstraction implemented by the RTE. This means that components cannot, for example, directly access operating system or communication services.
So, the RTE must present an abstraction over such services. It is essential that this abstraction remains unchanged, irrespective of the software components location. All interaction between software components therefore happens through standardized RTE interface calls.
In addition, the RTE is used for the specific realization of a previously specified architecture consisting of SWC on one or more ECUs. To make the RTE implementation efficient, the RTE implementation required for the architecture is determined at build time for each ECU. The standardized RTE interfaces are automatically implemented by an RTE generation tool that makes sure that the interface behaves in the correct way for the specified component interaction and the specified component allocation.
For example, if two software components reside on the same ECU they can use internal ECU communication, but if one is moved to a different ECU, communication now needs to occur across the vehicle network.
From the application software component perspective, the generated RTE therefore encapsulates the differences in the basic software of the various ECUs by:
• Presenting a consistent interface to the software components so they can be reused—they can be designed and written once but used multiple times.
• Binding that interface onto the underlying AUTOSAR basic software implemented in the VFB design abstraction.
3.3
AUTOSAR Elements in INTECRIO
The following AUTOSAR elements are supported in INTECRIO:
3.3.1
AUTOSAR Software Components
AUTOSAR software components are generic application-level components that are designed to be independent of both CPU and location in the vehicle network.
An AUTOSAR software component (SWC) can be mapped to any available ECU during system configuration, subject to constraints imposed by the system designer.
An AUTOSAR software component is therefore the atomic unit of distribution in an AUTOSAR system; it must be mapped completely onto one ECU.
Before an SWC can be created, its component type (SWC type) must be defined.
The SWC type identifies fixed characteristics of an SWC, i.e. port names, how ports are typed by interfaces, etc. The SWC type is named, and the name must be unique within the system. Thus, an SWC consists of
• a complete formal SWC description that indicates how the infrastructure of the component must be configured,
INTECRIO V4.6 - User’s Guide 45
46
INTECRIO and AUTOSAR ETAS
• an SWC implementation that contains the functionality (in the form of
C code).
To allow an SWC to be used, it needs to be instantiated as configuration time.
The distinction between type and instance is analogous to types and variables in conventional programming languages. You define an application-wide unique type name (SWC type), and declare one uniquely named variable of that type
(one or more SWC instance).
3.3.2
Ports and Interfaces
In the VFB model, software components interact trough ports which are typed by interfaces. The interface controls what can be communicated, as well as the semantics of communication. The port provides the SWC access to the interface.
The combination of port and port interface is named AUTOSAR interface .
There are two classes of ports:
• Provided ports (Pports) are used by an SWC to provide data or services to other SWC. Pports are implemented either as sender ports or as server ports.
• Required ports (Rports) are used by an SWC to require data or services from other SWC. Rports are implemented either as receiver ports or as client ports.
Tip
In the following, AUTOSAR ports are referred to as Rports or Pports, to avoid confusion with non-AUTOSAR ports.
INTECRIO V4.6 supports the following interface types:
• sender-receiver (signal passing)
• client-server (function invocation)
• calibration parameter interfaces
If an SWC contains other interfaces (i.e. an NVData interface or a ModeSwitch interface), these interfaces are skipped during import, and a warning is issued for each skipped interface.
Each Pport and Rport of an SWC must define the interface type it provides or requires.
If a system project is built from SWC instances, the Rports and Pports of the instances are connected. Senders must be connected with receivers, clients with servers.
Sender-Receiver Communication
Sender-receiver communication involves the transmission and reception of signals consisting of atomic data elements sent by one SWC and received by one or more SWC.
An SWC type can have multiple sender-receiver ports.
Each sender-receiver port can contain multiple data elements each of which can be sent and received independently. Data elements within the interface can be simple (integer, float, ...) or complex (array, matrix, ...) types.
INTECRIO V4.6 - User’s Guide
ETAS INTECRIO and AUTOSAR
Sender-receiver communication is one-way; each reply by a receiver must be modeled as separate sender-receiver communication.
An Rport of an SWC that requires a sender-receiver interface can read the data elements of the interface. A Pport that provides the interface can write the data elements.
In INTECRIO V4.6, sender-receiver communication can be only "
1:n
" (one sender, several receivers). " n:1
" (several senders, one receiver) is not supported in this version.
Client-Server Communication
Client-server communication involves an SWC invoking a defined server function in another SWC; the latter may or may not return a reply.
An SWC type can have multiple client-server ports.
Each client-server port can contain multiple operations that can be invoked separately. An Rport of an SWC that requires an AUTOSAR server interface to the
SWC can independently invoke any of the operations defined in the interface by making a client-server call to a Pport providing the service. A Pport that provides the client-server interface provides implementations of the operations.
Supported are several clients invoking the same server, i.e. " n:1
" with n
≥
0
.
It is not possible for a client to invoke multiple servers with a single request; several requests are necessary for that purpose.
Calibration Parameter Interfaces
Calibration parameter interfaces are used for communication with Calibration components.
Each calibration parameter interface can contain multiple calibration parameters.
A port of a software component that requires an AUTOSAR calibration interface to the component can independently access any of the parameters defined in the interface by making an RTE API to the required port. Calibration components provide the calibration interface and thus provide implementations of the calibration parameters.
3.3.3
Runnable Entities and Tasks
A runnable entity is a piece of code in an SWC that is triggered by the RTE (cf.
section 3.2) at runtime. It corresponds largely to the processes known in INTEC-
RIO.
A software component comprises one or more runnable entities the RTE can access at runtime. Runnable entities are triggered, among others, by the following events:
• Timing events represent some periodic scheduling event, e.g. a periodic timer tick. The runnable entity provides the entry point for regular execution.
• Events triggered by the reception of data at an Rport (DataReceive events).
AUTOSAR runnable entities can be sorted in several categories. INTECRIO supports runnable entities of category 1.
In order to be executed, runnable entities must be assigned to the tasks of an
AUTOSAR operating system.
INTECRIO V4.6 - User’s Guide 47
INTECRIO and AUTOSAR ETAS
Inter-Runnable Variables
The RTE allows the configuration of inter-runnable variables that provide a way for the runnable entities of a software component to communicate with each other. In INTECRIO, these inter-runnable variables can be measured during an experiment.
3.3.4
Runtime Environment
The runtime environment is described in section 3.2.
A RTE is—like the crossbar (section 2.5.5)—delivered with the INTECRIO installa-
tion. It is configured in INTECRIO via assignment of SWC to software systems, graphical connections and the OS configuration.
48 INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
4 The INTECRIO Components
INTECRIO consists of a series of base components and connectivity packages.
INTECRIO Integration Platform
Integration
OS Configurator
Experiment
Environment
RTA-Trace
Connectivity
Hardware
Configurator
Project Integrator
INCA
M ATLAB
®
/Simulink
Connectivity
®
INCA-EIP
INTECRIO-RP
ES1000
Connectivity
ES900
Connectivity
RTPRO-PC
Connectivity
Target connectivity
INTECRIO-VP
VP-PC
Connectivity
INTECRIO-RLINK rapid/virt. prototyping in M ATLAB /Simulink
Further INTECRIO-related tools and products
ASCET
Connectivity
INCA Connector
M ATLAB /Simulink back animation in INCA
RTA-RTE required for
AUTOSAR
Fig. 4-1 INTECRIO – components
(black: INTECRIO, light grey: ETAS tools that can be used to experiment with INTECRIO, dark grey: INTECRIO-related ETAS tools)
The project configurator (section 4.8), OS configurator (section 4.9), hardware
configurator (section 4.3) and project integrator (section 4.10) are indispensable
for working with INTECRIO; they are part of the INTECRIO integration platform.
The documentor (section 4.12) is also part of the INTECRIO integration platform.
The ETAS Experiment Environment (section 4.11), which includes RTA-TRACE
connectivity (section 4.13), INCA and INCA-EIP are separate products. The ETAS
experiment is shipped with INTECRIO; INCA and INCA-EIP have to be purchased individually.
Target Connectivity: The INTECRIO-RP package provides connectivity to the
rapid prototyping hardware, i.e. ES1000 (section 4.4), ES900 (section 4.5) and
RTPRO-PC (section 4.6), and the INTECRIO-VP package provides connectivity to
the PC (section 4.7) and all prerequisites for virtual prototyping.
BMT Connectivity: Different behavioral modeling tools or BMTs allow users to model the functionality of the application software. The models are integrated in the system project. Checking or editing the models is not part of INTECRIO;
INTECRIO only serves as integration tool in this context.
INTECRIO V4.6 - User’s Guide 49
50
The INTECRIO Components ETAS
• M ATLAB® /Simulink ®
connectivity (cf. section 4.1) is provided by the INTEC-
RIO integration platform directly.
• ASCET connectivity (cf. section 4.2)
In ASCET V6.3 and higher, ASCET connectivity is integrated in ASCET-MD.
In ASCET V6.2 and lower, ASCET connectivity is available as a separate add-on named INTECRIO-ASC, or as a part of ASCET-RP. You can install it directly from the ASCET installation medium, according to your needs.
The license is included with the license for the INTECRIO integration platform.
Other Tools and Products: If you want to use an executable file created with
INTECRIO for an INCA experiment, the INCA connector
access to the M ATLAB /Simulink back animation, provided M ATLAB /Simulink is installed on your computer and the INTECRIO integration platform is not installed.
INTECRIO-RLINK allows the creation of rapid-prototyping and virtual prototyping experiments from within M ATLAB /Simulink. INTECRIO-RLINK has to be purchased individually.
The RTA-RTE
tool provides the runtime environment (see section 3.2 on page 44)
required for AUTOSAR.
4.1
M
ATLAB®
/Simulink
®
Connectivity
Real-Time Workshop
M ATLAB
® /Simulink ®
®
(optional: RTW Embedded Coder TM )
M ATLAB
® Coder TM
Simulink ® Coder TM
(optional: Embedded Coder TM )
INTECRIO
MATLAB ® /Simulink ® Connectivity
C code Description file
(SCOOP-IX)
Description file
(ASAM-2MC)
Software component
INTECRIO
Integration platform
Fig. 4-2 INTECRIO-IP: M ATLAB® /Simulink ® connectivity
M ATLAB /Simulink connectivity is provided by the INTECRIO integration platform without the need of further add-on installations. The integration platform contains everything required for a successful linking of Simulink models in INTECRIO for integration and rapid prototyping.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
It allows the integration of code generated by the Real-Time Workshop ®
Time Workshop ® Embedded Coder TM (R2011a and higher: M ATLAB
®
or Real-
Coder TM +
Simulink ® Coder TM + (optional) Embedded Coder TM ).
M ATLAB /Simulink versions R2009a – R2015b (both 32 bit and 64 bit) and their related service packs known at the time of the INTECRIO V4.6 release are supported. If several supported M ATLAB /Simulink versions (e.g. R2011b and R2014a) are installed, all of them are supported at the same time.
Unsupported M ATLAB /Simulink versions cannot be used to create code for use with INTECRIO.
Model code created with M ATLAB /Simulink R2006b – R2008b can still be imported and integrated in INTECRIO V4.6. However, back animation is not available for such a model.
During the installation of M ATLAB /Simulink connectivity, the M ATLAB /Simulink installation is adjusted so that M ATLAB /Simulink can interact with INTECRIO.
M ATLAB /Simulink connectivity has the following tasks:
• Providing the INTECRIO target irt.tlc
that must be selected if the
Simulink model must be further processed with INTECRIO.
• Providing the INTECRIO target ier.tlc
that must be selected if the
Simulink model to be used in INTECRIO was created with Real-Time Workshop Embedded Coder (R2011a and higher: M ATLAB Coder + Simulink
Coder + Embedded Coder).
• Providing the automatic creation of the SCOOP-IX description file (see
chapter 5) during code generation with one of the following setups:
– Real-Time Workshop (RTW) or M ATLAB Coder + Simulink Coder
– Real-Time Workshop Embedded Coder or M ATLAB Coder + Simulink
Coder + Embedded Coder
The contents of this description file is explained in section 4.1.2.
• Providing the option to start the integration in a newly created INTECRIO system and the INTECRIO build process directly from Simulink (one-click prototyping).
• Providing the option for back animation of a Simulink model during the experiment.
Back animation means that the model variables can be displayed on the
Simulink display devices and that calibration variables can be calibrated directly from within the Simulink model while the experiment is running in real-time.
Tip
Due to a limitation in Simulink, simultaneous back animations for several
Simulink models or the animation of state machines is not possible.
• Automatic re-import of the model in INTECRIO after changes and new code generation in Simulink.
If no M ATLAB /Simulink installation was available during INTECRIO installation, or if you want to change the M ATLAB /Simulink version associated with INTECRIO, proceed as follows.
INTECRIO V4.6 - User’s Guide 51
The INTECRIO Components ETAS
To connect INTECRIO and M ATLAB /Simulink subsequently:
Tip
If you want to use a network installation of M ATLAB /Simulink, click on the Help button and follow the instructions given in the message window.
• Install M ATLAB /Simulink as described in the relevant installation instructions.
• In the Windows Start menu, INTECRIO folder, select
Connectivity → Associate with Matlab .
The "Association with Matlab" window opens. It offers all supported M ATLAB /Simulink installations available on your system for selection.
52
• In the "Association with Matlab" window, select one or more M ATLAB /Simulink installations.
• Click OK to continue.
If at least one selected M ATLAB /Simulink installation is R2011a or later, a message window opens and informs you that the legacy ASAM-MCD-2MC generation is only partly compatible with R2011a and higher and cannot be used with R2013b and above
.
• Read the message text carefully, then click OK .
INTECRIO and the selected M ATLAB /Simulink installation(s) are connected.
4.1.1
Characteristics in the Creation of the Simulink Model
Several points must be observed when creating the Simulink model for later use with INTECRIO. Only the most important points are listed here; additional infor-
mation about modeling in Simulink can be found in section 6.2 "Modeling with
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
• Only the signal ports of the top-level hierarchy of the model are recognized as signal sources or sinks in INTECRIO.
Tip
Signal ports from lower levels of the hierarchy are not recognized as signal sources or sinks. (Exceptions are listed in the INTECRIO section in the
M ATLAB /Simulink online help viewer.)
• INTECRIO supports floating-point code that was generated with RTW /
RTW Embedded Coder or M ATLAB Coder + Simulink Coder (+ Embedded
Coder).
This entails that all Simulink blocks for which code can be generated with
RTW or M ATLAB Coder + Simulink Coder are supported.
• INTECRIO target irt.tlc
or ier.tlc
must be selected for the code generation to create the SCOOP-IX file.
• INTECRIO allows for the integration of several Simulink models. Each model can be assigned a different integration algorithm (solver for continuous states) with fixed step width.
4.1.2
Contents of the Description File
The interface description file that is automatically created during the code generation, the SCOOP-IX file, contains the following information if they were specified in Simulink:
• Signal sources and sinks (inports and outports of the highest modeling level)
– Name
– Physical value range
– Implementation data type and value range (can also be calculated using the physical value range and the quantization formula)
– Quantization formula
• A signal for each one-dimensional Simulink signal
• One signal for the real part and one signal for the imaginary part of a complex Simulink signal
• Parameters and variables (no distinction is made between one, two and three-dimensional quantities)
– Name
– Physical value range
– implementation data type and quantization
– Hierarchical information, i.e. the exact location of the quantity in the model
• Activation interfaces (processes)
– Timing information for cyclical processes
INTECRIO V4.6 - User’s Guide 53
The INTECRIO Components ETAS
54
4.2
ASCET Connectivity
ASCET-MD
ASCET-RP
ASCET Connectivity
ASCET-MD (since V6.3) / INTECRIO-ASC (til V6.2)
C code Description file
(SCOOP-IX)
Description file
(ASAM-2MC)
Software component
INTECRIO
Integration platform
Fig. 4-3 ASCET connectivity
ASCET Connectivity contains everything required for a successful linking of
ASCET models in INTECRIO for integration and rapid prototyping.
In ASCET V6.2 and earlier, ASCET connectivity is available as an add-on named
INTECRIO-ASC. During the installation of INTECRIO-ASC, the required files and settings are automatically inserted in the existing ASCET installation. INTEC-
RIO-ASC supports ASCET V5.1 – V6.2; if several ASCET versions are installed, all of them are supported at the same time.
1
In ASCET V6.3 and higher, ASCET connectivity is included in ASCET-MD. Nothing else has to be installed.
ASCET connectivity has the following tasks:
• Providing the targets
Prototyping
,
ES1130
,
ES1135
,
ES900
and
RTPRO-PC
, one of which must be selected if the ASCET model is to be further processed with INTECRIO.
• Selection of INTECRIO as rapid prototyping environment in the project editor of ASCET.
• In the context of an ASCET project, provision of a special code generation for INTECRIO in which all required files (C code, ASAM-MCD-2MC file,
SCOOP-IX description file) are created.
The contents of the SCOOP-IX description file is explained in section 4.2.2.
In addition, an
*.oil
file is generated that contains the OS configuration.
This file can be manually imported into INTECRIO.
• If the ASCET code generation for INTECRIO is used, automatic import of the project in INTECRIO.
1. Besides INTECRIO-ASC, ASCET-RP V5.3 – V6.2 provide ASCET connectivity. If
ASCET-RP is found on a PC, INTECRIO-ASC cannot be installed.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
• Adjusting the handling of non-resolved global variables and messages to the needs of INTECRIO.
• Providing options for the migration of existing projects.
• Providing the option to start the integration in an INTECRIO system and the INTECRIO build process directly from ASCET (one-click prototyping).
• Providing the option for back animation of an ASCET model during the experiment.
Back animation means that the model variables can be displayed on the
ASCET display devices and that calibration variables can be calibrated directly from within the ASCET model.
Tip
Unlike with Simulink, simultaneous back animations for several ASCET models and the animation of state machines are possible.
• Automatic re-import of the model in INTECRIO after changes and new code generation in ASCET.
4.2.1
Characteristics in the Creation of the ASCET Model
When you create an ASCET model for later use with INTECRIO, you can make use of all ASCET facilities. Keep in mind the following points:
• Receive messages without corresponding send messages form the signal sinks in INTECRIO, send messages without corresponding receive messages form the signal sources in INTECRIO.
If desired, you can make connected messages appear as signal sinks and sources, too.
• When your project contains unresolved messages (imported messages without corresponding export), code generation for INTECRIO produces an error message.
You can resolve the messages automatically, or cancel code generation and resolve the messages manually.
• Using global variables and parameters is possible, but strongly discouraged.
• In the project options, you must select an appropriate target so that code generation for INTECRIO is available.
• To use cache locking
(see also page 64), make the respective settings for
the various model elements in ASCET.
4.2.2
Contents of the Description File
The interface description file that is automatically created during the code generation, the SCOOP-IX file, contains the following information if they were specified in ASCET:
• Signal sources (send messages) and signal sinks (receive messages)
– Name
– Physical value range
INTECRIO V4.6 - User’s Guide 55
56
The INTECRIO Components ETAS
– Implementation data type and value range (can also be calculated using the physical value range and the quantization formula)
– Quantization formula
• Parameters and variables (no distinction is made between one, two and three-dimensional quantities)
– Name
– Physical value range
– implementation data type and quantization
– Hierarchical information, i.e. the exact location of the quantity in the model
• Activation interfaces (processes)
– Timing information for cyclical processes
4.3
The Hardware Configurator
During the development of a control algorithm, the actual controlled system must be addressed at some time so that realistic results can be achieved. The controlled system (or the technical process) appears to the rapid prototyping system as a set of sensors and actuators with which the system can be connected using a series of appropriate peripheral devices.
These peripheral devices must be configured so that they fit the actual technical process that must be modeled. For example, for A/D converters it is possible to configure the input range, scanning/keeping, etc. In addition, the signal must be conditioned to adjust it to the control algorithm. The conditioning essentially consists of converting measured electrical signals to physical signal values.
These tasks are handled by the Hardware Configurator and the target connectiv-
ity packages (sections 4.4, 4.5, 4.6 and 4.7) in INTECRIO.
If an algorithm passed the first general validation check in the virtual model, it can be examined for errors, refined and optimized until it meets the specified requirements of functionality, quality and code size. As a direct troubleshooting option, the Hardware Configurator offers, for example, to measure the signal values of the hardware directly in the ETAS Experiment Environment.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
4.3.1
HWX Import
As an alternative to manual configuration (see section 4.4.1, section 4.5.1 or
section 4.6.1), it is possible to import a hardware description
1 (
*.hwx
file). For that purpose, INTECRIO provides the necessary context menu options and dialog windows.
Tip
If the
*.hwx
file contains an ETK/XETK/FETK/XCP configuration with ASAM-
MCD-2MC file, the respective
*.a2l
file has to be provided and imported in addition to the
*.hwx
file.
An ASAM-MCD-2MC file that was exported by ASCET may cause errors when imported in INTECRIO. It is thus strongly recommended to use only original
ASAM-MCD-2MC files.
The file extension
*.hwx
is used for two description formats, HWX1 and HWX2.
• The HWX1 format is the only available format used by ASCET-RP V6.0 and earlier; it is also used by the legacy HWC editor in ASCET-RP V6.1 and higher.
• The HWX2 format is used by INTECRIO V3.2 and higher and by the Hardware Configurator in ASCET-RP V6.1 and higher.
INTECRIO recognizes the format automatically and switches to the appropriate import procedure.
The hardware description is mapped onto an existing or new ES1000, ES900,
RTPRO-PC or VP-PC hardware system during import.
The log window displays a list with information about the import procedure.
If the
*.hwx
file contains boards or elements not supported by INTECRIO and the selected target, these boards or elements are skipped, and warnings are issued. If the
*.hwx
file contains an ES1232 with ETK-CTRL-BAS, this board is mapped to an ES1232 in INTECRIO.
4.3.2
Ethernet Controller and XCP on UDP
The Rapid Prototyping targets ES1135, ES910 and RTPRO-PC support one
Ethernet controller which can be used for XCP bypass on UDP and – for ES910 –
X/FETK bypass. The Ethernet controller supports up to four XCP on UDP interfaces and one X/FETK bypass device.
Tip
In a hardware system, 4 is the maximum number of all XCP interfaces, i.e. XCP on UDP and XCP on CAN.
1. created with INTECRIO, with ASCET V6.3 or higher, ASCET V5.1 – V6.2 and
INTECRIO-ASC or ASCET-RP V5.3 (or higher), with INTECRIO-RLINK or
INCA-VLINK, or with customer-specific ASCET extensions
INTECRIO V4.6 - User’s Guide 57
58
The INTECRIO Components ETAS
Fig. 4-4 shows the schematic structure of the Ethernet controller and XCP on
UDP in the WS browser.
Target (ES1000 / ES900 / RTPRO-PC)
ES1135 / ES910 / X86
Ethernet_Controller
XCP_on_UDP_IP
Rasters
Signal group(s)
Signal(s)
Status
Status signal group(s)
Status signal(s)
Fig. 4-4 Ethernet and XCP on UDP structure in the WS browser
4.3.3
XXX to CAN Gateway
The XXX to CAN Gateway functionality serves to generate a gateway from an
ETK, X/FETK, XCP on CAN or XCP on UDP device to a CAN device. The signal interfaces between the devices are generated in a semi-automated way; the behavior is controlled by an
*.xml
settings file. For details, see the online help.
4.4
ES1000 Connectivity and Hardware Configurator
INTECRIO V4.6 supports the ES1000.2 and ES1000.3 hardware. In combination with ES1000 connectivity (provided in the INTECRIO-RP package), the Hardware
Configurator ( HC ) is provided for the integration and configuration of this hardware.
Tip
The ES1000 configuration capabilities of the Hardware Configurator are only available if you installed the INTECRIO-RP package and have an appropriate license key.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
INTECRIO
Integration platform (including HC)
INTECRIO-RP
ES1000 Connectivity
*.cod
*.a2l
ES1000
Fig. 4-5 INTECRIO-RP: ES1000 connectivity
The Hardware Configurator allows the configuration of ES1000 hardware systems (in form of boards or groups of boards) to provide real physical signals for model inputs and outputs which can be linked with the software function model
in the project configurator (see section 4.8). While the Hardware Configurator is
used to configure boards that will be available in the ES1000 for the experiment, they do not have to be installed at the time of configuration.
Information about the individual boards can be found in section 4.4.2 and in the
manuals of the ES1000 boards.
4.4.1
Configuring the ES1000 in the Hardware Configurator
The Hardware Configurator contains the following components required for the
ES1000 configuration:
• A framework that is independent of the hardware, and that provides the basic editor and connections to other INTECRIO components (e.g. OS configurator, project integrator, ETAS Experiment Environment), among others.
• A specific expansion of the basic editor for each board supported by
INTECRIO. Each of these expansions allows for the configuration of the respective board based on parameters that are displayed in various tabs registers.
• A generator for the configuration of the RTIO device drivers.
• Real-time I/O device driver.
These components can be used for the following tasks:
INTECRIO V4.6 - User’s Guide 59
60
The INTECRIO Components ETAS
• Configuring real-time I/O boards (e.g. defining input ranges or scanning frequencies)
• Assigning input or output actions for operating system tasks (defined in the OS configurator)
• Providing conversion formulas for describing the mapping of physical signals (model view) to raw values (driver view)
The current hardware system is displayed in the WS browser as a tree structure.
The ES1000 itself is located in the
Hardware/Hardware Systems
folder on the top level, the current simulation controller board (e.g. ES1130 or ES1135) is shown on the level directly underneath it. This board is the master with which all other boards used in the ES1000 are linked as slaves. The available hardware signals are placed in a lower hierarchy level. Each level has parameters that can be adjusted in appropriate editors. These editors are opened in the display window.
INTECRIO Vx.y
File Edit View ...
WS browser
HC Element Name
3
4
1
2
Name
Name
Parameter 1
...
Parameter n
Value
<Name>
<Value 1>
...
<Value n>
HC Element Name
Comment
Scripting window
Message window
Fig. 4-6 Hardware Configurator – diagram
The entry (board, device, signal group, signal) to be edited is selected in the WS browser, while the corresponding editor is opened in the display window. It is possible to edit several objects at the same time.
The editor lists all parameters of the respective object in tables. Number and names of the parameters and registers depend upon the object.
Manual Configuration: In offline mode, the Hardware Configurator allows for the configuration of the boards supported by INTECRIO to build a hardware system. The following points must be observed when the board hierarchy is created:
• Only a single ES1000 can be selected.
• A board hierarchy consists of a master board and one or several slave boards controlled by the master board.
• Only one controller board (either ES1130 or ES1135) can be selected as master board for a configuration.
• All the slave boards are located on the same hierarchy level; a slave board cannot have its own slave boards.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
• Each slave board is assigned to its master board.
• Several slave boards of the same type can be installed in an ES1000. Tab.
4-1 lists the available numbers of boards.
ES1130 ES1135
ES1222 0 – 4 0 – 4 Each ES1222 supports up to 4 CAN devices.
ES1232 0 – 4
ES1300
ES1303
0 – 4
0 – 4
0 – 4 Each ES1232 supports one ETK bypass device which can be used for hook-based and service-based bypass.
0 – 4
0 – 4
ES1310 0 – 3 0 – 3
ES1320 0 – 16 0 – 16
ES1325 0 – 4 0 – 4
ES1330 0 – 4 0 – 4
Tab. 4-1 Number of boards per controller board
• For the boards ES1300, ES1310, ES1320 and ES1330, it must be ensured that each card features a unique address if several boards of the same type are used since all boards of a type are equipped with the same predefined basic address.
For the remaining boards, the address is automatically assigned.
In each case, it must be ensured that the address of the board to be used is correctly set in the Hardware Configurator.
• Boards of different types can be assigned to a master board.
• For some boards (e.g. PWM board), it is possible to define sublevels that serve as devices. Each of these sublevels can contain additional sub-hierarchies.
Tip
During insertion, the Hardware Configurator offers a list with objects that may be inserted at the current location of the tree view.
Boards, devices and other sublevels can be inserted in the hierarchy, and deleted when these points are taken into account.
The boards, devices, signal groups and signals of the hardware system can be configured in the Hardware Configurator. The following points must be observed during the configuration of the boards:
• Hardware settings via jumpers on a board override software settings in the board-specific editors of the Hardware Configurator.
• While a series of board parameters (such as the input voltage levels) are set at the factory, the tasks and processes associated with the signals/ signal groups are defined in the OS configurator. All signals of a signal group are processed at the same time.
INTECRIO V4.6 - User’s Guide 61
The INTECRIO Components ETAS
• During the configuration of individual signals, conversion formulas for sensors and actuators can be specified. The following formulas are available:
– Identity: f(phys) = phys
– linear: f(phys) = a*phys + b
(I/O signals) or f(phys) = a/b*phys + d/c
(signals with complete implementation information
such as CAN or ETK signals)
• An implementation (i.e. a conversion formula and a valid value range) can be specified for CAN signals.
Parts of the hardware system can be copied or shifted via Copy and Paste . The settings of the target parts are overwritten; if no target part is selected, a new one is created.
Import: As an alternative to manual configuration, it is possible to import a hardware description (
*.hwx
file); see "HWX Import" on page 57.
4.4.2
Board Types and Supported Boards
Boards can be used for rapid prototyping of control algorithms of motor vehicles to read and process the physical parameters and conditions and forward them to model input signals. On the other hand, model output signals can be forwarded to the outside world using the boards.
The use of I/O signal boards allows working with physical parameters and conditions before any actual controller hardware is being used. For example, an A/D board can be used to provide temperature values for the controller model, or a wheel angular encoder can furnish measured values for an ABS system.
62 INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
Tab. 4-2 contains the board classes for the ES1000 and the names of the boards
supported by INTECRIO. The listed boards of the ES1000 can be configured using the Hardware Configurator.
Board class Name of board Description
Simulation controller board ES1130.2
Controller board with Ethernet
ES1135
A/D or D/A board
DIO board
PWM board
Communication board
ES1300.1
ES1303.1
ES1310
ES1320
ES1325
ES1330.1
ES1222.3 A
ES1232
Controller board with Ethernet
A/D board
Expanded A/D board
D/A board
Digital I/O board (DIO)
Enhanced digital I/O board (DIO); offers also PWM functionality
Acquired pulse widths and pulse duty cycles
CAN board
ETK board, supports hook-based bypass and service-based bypass.
Tip
On ES1000 systems, INTECRIO supports both ETK (ES1130, ES1135) and XETK
(ES1135 only). XETK is supported via the XCP on UDP configuration, i.e. using an Ethernet controller with XCP device in the INTECRIO hardware configuration. To connect the XETK hardware, port 2 on the ES1135 is used.
See the INTECRIO online help for details on XETK configuration.
Tab. 4-2 Board classes of the ES1000 and names of supported boards
Fig. 4-7 shows the schematic structure of the boards in the WS browser.
ES1000
ES113x
Board
Device (not A/D / D/A boards)
Signal group(s)
Signal(s)
Fig. 4-7 Display of the boards in the WS browser
INTECRIO V4.6 - User’s Guide 63
64
The INTECRIO Components ETAS
Simulation controller boards: Simulation controller boards (ES113x in
Fig. 4-7) serve as system controller for the use with VME bus systems. These
boards are equipped with a main processor and a communication processor with
VME bus interface. The VME bus interface of the communication processor of these boards is configured for master and slave access.
ES1135 supports cache locking , i.e. the possibility to mark highly time-critical parts of the model and thus make sure that they are always available in the cache. However, this possibility is available only for ASCET models because detailed cache locking settings for various model elements are made in ASCET.
In INTECRIO, only a few basic cache locking settings can be made in the system project properties.
Ethernet interface / XCP on UDP:
A/D or D/A boards: A/D boards are used for analog data acquisition in VME bus systems, D/A boards for analog data output in VME bus systems.
• In the tree view, the top hierarchy level (underneath the ES113x) of this board class combines the card and the device.
• The second hierarchy level is occupied by the signal groups.
• The third hierarchy level is occupied by the individual signals.
DIO boards: DIO boards are used in VME bus systems for the acquisition and generation of digital switching signals.
ES1320
• In the tree view, the top hierarchy level of the ES1320 contains the board.
• The second hierarchy level is occupied by the device. Up to two devices can be defined for each ES1320.
• The third hierarchy level is occupied by the two signal groups for outputs and inputs.
• The fourth hierarchy level is occupied by the individual signals (10 input and output signals each).
ES1325
• For the ES1325, the top hierarchy level contains the board.
• The second hierarchy level is occupied by the device. Three device types are available; up to one device of each type can be defined for each
ES1325.
• The third hierarchy level is occupied by the signal groups. The number of signal groups depends on the device.
Tip
The configuration of a signal group determines whether the group is used for the acquisition/generation of digital signals or for the acquisition/generation of pulse widths, pulse duty cycles and PWM signals.
• The fourth hierarchy level is occupied by the individual signals.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
PWM boards: PWM boards are used to acquire pulse widths and pulse cycle factors in VME bus systems. PWM boards are also used for generating PWM signals of different frequencies and pulse duty cycles.
• In the tree view, the top hierarchy level of this board class contains the board.
• The second hierarchy level is occupied by the device. Up to six devices can be defined for each PWM board.
• The third hierarchy level is occupied by the generator signal group and/or the measuring signal group of each device.
• The fourth hierarchy level is occupied by the signals of each generator or each measurement.
Communication boards: Communication boards are used for distributing messages on the network (such as the CAN bus). The display of supported communication boards in the Hardware Configurator varies so much that both of them are described below.
ES1222
• For the ES1222, the top hierarchy level contains the board.
• The second hierarchy level is occupied by the CAN node (device, CAN IO).
• The third hierarchy level is occupied by folders for CAN frames (signal groups) and/or CAN signals.
Underneath the folder for CAN frames , the hierarchy levels are occupied as follows:
– The fourth hierarchy level is occupied by CAN frames (signal groups).
– The fifth hierarchy level is occupied by simple CAN signals and/or CAN signals of type multiplexor .
– The sixth hierarchy level is occupied by CAN multiplex groups under a
CAN signal of type multiplexor .
– The seventh hierarchy level under the CAN multiplex group is occupied by CAN signals of type multiplexed .
Underneath the folder for CAN signals , the hierarchy levels are occupied as follows:
– The fourth hierarchy level is occupied by CAN signals of type standard .
INTECRIO V4.6 - User’s Guide 65
66
The INTECRIO Components ETAS
ES113x (E-Target)
<name>:ES1222 (CAN Board)
ES1222NodeDevice
Frames
ES1222NodeSignalGroup
<CAN Signal Name>
<CAN Multiplexor Signal Name>
<CAN Multiplex Group Name>
<CAN Multiplexed Signal Name>
Signals
<CAN Signal Name>
Fig. 4-8 Display of the ES1222 communication board in the WS browser
ES1232
• For the ES1232, the top hierarchy level contains the board.
• The second hierarchy level is occupied by the ETK bypass device.
Tip
The ES1232 supports hook-based and service-based bypass (V2 only). Both types can be used separately or in parallel.
INTECRIO does not support service-based bypass on an ETK with 8 Mbit/s.
For a hook-based bypass, the levels underneath the bypass device are occupied as follows:
– The third hierarchy level is occupied by the signal groups for sending and receiving.
– The fourth hierarchy level is occupied by individual signals.
For a service-based bypass, the levels underneath the bypass device are occupied as follows:
– The third hierarchy level is occupied by the service points.
The ASAM-MCD-2MC file contains service point descriptions. Number and configurations of the service points actually used in the bypass are determined in the service point selection editor.
– The fourth hierarchy level is occupied by the signal groups for sending and receiving.
The available signal groups depend on the settings made in the service point selection editor.
– The fifth hierarchy level is occupied by individual signals.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
Two variants of the experimental target ES1000 are supported: ES1000.2 and
ES1000.3. Both can contain the board types listed above, but only one system
controller board underneath them. Tab. 4-1 on page 61 indicates how many
boards of a type can be used with which system controller board.
4.5
ES900 Connectivity and Hardware Configurator
INTECRIO V4.6 supports the ES900 hardware, i.e. the ES910.2 and ES910.3 rapid prototyping modules and the ES920 (FlexRay) and ES921 (additional CAN) modules. The ES4xx, ES63x and ES930 modules are supported, too. In combination with ES900 connectivity, the Hardware Configurator (HC) is provided for the integration and configuration of this hardware.
Tip
The ES900 configuration capabilities of the Hardware Configurator are only available if you installed the INTECRIO-RP package and have an appropriate license key.
INTECRIO
Integration platform (including HC)
INTECRIO-RP
ES900 Connectivity
*.cod
*.a2l
ES900
ES930
ES4xx
...
ES63x
Fig. 4-9 INTECRIO-RP: ES900 connectivity
The Hardware Configurator allows the configuration of ES900 hardware systems to provide real physical signals for inputs and outputs of the model, which can be linked with the software function model in the project configurator (see
section 4.8). It is used to configure interfaces available in the ES900 for the
experiment. They do not have to be installed at the time of configuration.
Information about the individual interfaces can be found in section 4.5.2 and in
the manuals of the hardware products.
INTECRIO V4.6 - User’s Guide 67
68
The INTECRIO Components ETAS
4.5.1
ES900 Configuration in the Hardware Configurator
The Hardware Configurator contains the following components required for
ES900 configuration:
• A framework that provides the basic editor and connections to other
INTECRIO components (e.g. OS configurator, project integrator, ETAS
Experiment Environment), among others.
• A specific expansion of the basic editor for each interface supported by
INTECRIO. Each of these expansions allows for the configuration of the respective interface based on parameters that are displayed in various tabs.
• A generator for the configuration of the device drivers.
These components can be used for the following tasks:
• Configuring interfaces (or loading a daisy chain, CAN, FlexRay or LIN configuration)
• Assigning input or output actions for operating system tasks (defined in the OS configurator)
• Providing conversion formulas for describing the mapping of physical signals (model view) to raw values (driver view)
The current hardware system is displayed in the WS browser as a tree structure.
The ES900 itself is located in the
Hardware/Hardware Systems
folder on the top level, the current simulation controller (ES910) is shown on the level directly underneath it. This is the master with which all other interfaces are linked as slaves. The available hardware signals are placed in a lower hierarchy level.
Each level has parameters that can be adjusted in appropriate editors. Their
appearance is the same as for the ES1000 interface editors (cf. Fig. 4-6 on page 60).
The entry (controller, device, signal group, signal) to be edited is selected in the
WS browser, while the corresponding editor is opened in the display window. It is possible to edit several objects at the same time.
The editor lists all parameters of the respective object in tables. Number and names of the parameters and registers depend upon the object.
Manual Configuration: In offline mode, the Hardware Configurator allows for the configuration of the interfaces supported by INTECRIO to build a hardware system. The following points must be observed when the board hierarchy is created:
• Only a single ES900 can be selected.
• A hierarchy consists of a system controller as master and one or several slave interfaces controlled by the master.
• Only one system controller (ES910) can be selected as master for a configuration.
• All the slave interfaces are located on the same hierarchy level; a slave interface cannot have its own slave interfaces.
• Each slave interface is assigned to its master.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
• Some interfaces are present several times in an ES900 system. Tab. 4-3
lists the available numbers of interfaces.
ES910 Remarks
CAN Controller 0 – 2 (4) two additional CAN interfaces with ES921
XCP_on_CAN (via
CAN controller)
LIN
ETK Bypass
0 – 4
0 – 2
0 – 1
4 is the maximum number of all XCP interfaces, i.e. XCP_on_CAN and XCP_on_UDP.
The LIN interfaces use the same ES910 hardware connectors as the main two CAN interfaces.
With a suitable cable, you can use CAN and
LIN simultaneously.
Can be used as hook-based bypass or service-based bypass.
SystemDevice 0 – 1
ES920 (FlexRay) 0 – 1
0 – 1 Daisychain
(IO interface)
Ethernet and
XCP_on_UDP
0 – 4
Ethernet and
X/FETK_Bypass
0 – 1
A chain of ES4xx and/or ES63x and/or
ES930 modules.
See section 4.3.2 on page 57 for details.
4 is the maximum number of all XCP interfaces, i.e. XCP_on_CAN and XCP_on_UDP.
Can be used as hook-based bypass or service-based bypass.
The device is named
Bypass
for both XETK and FETK.
Tip
INTECRIO supports ETK, XETK and FETK on ES900 systems. X/FETK bypass is supported via the Ethernet controller with an X/FETK_Bypass device in the INTECRIO hardware configuration. In addition, XETK can be accessed via XCP_bypass.
To connect the XETK hardware, the ECU port on the ES910 is used.
To connect the FETK , an ES891 must be connected via its FETK2/GE Port to the ECU Port of the ES910. The FETK must be connected to the ES891 via its FETK1/GE Port.
See the INTECRIO online help for details on X/FETK configuration.
Tab. 4-3 Number of interfaces/elements per system controller
• For the CAN interfaces, it must be ensured that each interface features a unique ID.
For the remaining interfaces, the ID is automatically assigned.
In each case, it must be ensured that the ID of the interface to be used is correctly set in the Hardware Configurator.
INTECRIO V4.6 - User’s Guide 69
70
The INTECRIO Components ETAS
• Interfaces of different types can be used with a master.
Tip
During insertion, the Hardware Configurator offers a list with objects that may be inserted at the current location of the tree view.
Interfaces, devices and other sublevels can be inserted in the hierarchy, and deleted when these points are taken into account.
The interfaces, devices, signal groups and signals of the hardware system— except the daisy chain which is configured in a separate configuration tool—can be configured in the Hardware Configurator. The following points must be observed during the configuration:
• While a series of interface parameters are preset, the tasks and processes associated with the signals/signal groups are defined in the OS configurator. All signals of a signal group are processed at the same time.
• During the configuration of individual signals, conversion formulas for sensors and actuators can be specified. The following formulas are available:
– Identity:
– linear: f(phys) = phys f(phys) = a*phys + b
• An implementation (i.e. a conversion formula and a valid value range) can be specified for CAN signals.
• ES920 (FlexRay) and ES921 (additional CAN controllers) can be configured in the same hardware system, even though only one plugin module can be connected to the ES910.
At runtime, only that plugin module actually present in the hardware is activated. The other plugin module produces an error message.
It is thus recommended to set the ES910 parameter "I/O Failure Behavior" to continue
so that the experiment continues despite the error. (Otherwise, the experiment is stopped immediately due to the error.)
The RP model can use the Presence flag to check whether a configured plugin module is actually available and ready for use, and act accordingly.
• Up to four CAN controllers and two LIN controllers can be configured in the same hardware system. To access all of them at runtime, you need a suitable cable.
Parts of the hardware system can be copied via Copy and Paste . The settings of the target parts are overwritten; if no target part is selected, a new one is created.
Import: As an alternative to manual configuration, it is possible to import a hardware description (
*.hwx
file); see "HWX Import" on page 57.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
4.5.2
Interface Types and Supported Interfaces
Tab. 4-4 contains the interface classes for the ES900 and the names of the inter-
face supported by INTECRIO. The listed interfaces of the ES900 can be configured using the Hardware Configurator.
Interface class Name
Simulation controller ES910
Communication interfaces
CAN_Controller +
CAN_IO
CAN_Controller +
XCP_on_CAN
IO interface
System interface
Description system controller
CAN IO interface
XCP bypass on CAN
ETK_Bypass
LIN_Controller
ETK interface
LIN interface
ES920
Daisychain
FlexRay interface
Ethernet_Controller Interface for XCP bypass on UDP and
XETK/FETK bypass
A chain of ES4xx and/or ES63x and/or
ES930 modules; connected to the IO interface
SystemDevice controls display and monitoring modes
Tab. 4-4 Interface classes of the ES900 and names of supported interfaces/ elements
Tab. 4-3 on page 69 indicates how many interfaces of a type can be used with
which system controller.
Fig. 4-10 shows the schematic structure of the interfaces in the WS browser.
ES900
ES910
Controller (CAN, LIN, Ethernet)
Device
Signal group(s)
Signal(s)
Fig. 4-10 Display of the interfaces in the WS browser
Simulation controller:
The simulation controller (ES910 in Fig. 4-10) is
equipped with an Ethernet interface (named ECU on the ES910) for XCP on UDP and XETK/FETK, interfaces to the CAN, LIN and FlexRay bus of the vehicle, and an
ETK interface.
INTECRIO V4.6 - User’s Guide 71
72
The INTECRIO Components ETAS
Communication interfaces: Communication interfaces are used for distributing messages on the network (such as the CAN bus). The display of supported communication interfaces in the Hardware Configurator varies so much that all are described below.
CAN Controller + CAN IO
• In the tree view, the first hierarchy level (i.e. the one underneath the
ES910) is occupied by the CAN controller.
• The second hierarchy level is occupied by the CAN node (device, CAN IO).
• The third hierarchy level is occupied by folders for CAN frames (signal groups) and CAN signals.
Underneath the folder for CAN frames , the hierarchy levels are occupied as follows:
– The fourth hierarchy level is occupied by CAN frames (signal groups).
– The fifth hierarchy level is occupied by simple CAN signals and/or CAN signals of type multiplexor .
– Underneath a CAN signal of type multiplexor, the sixth hierarchy level is occupied by CAN multiplex groups.
– The seventh hierarchy level under the CAN multiplex group is occupied by CAN signals of type multiplexed .
Underneath the folder for CAN signals , the hierarchy levels are occupied as follows:
– The fourth hierarchy level is occupied by CAN signals of type standard .
ES910 (E-Target)
CAN_Controller
CAN_IO
Frames
<Signal Group Name>
<CAN Signal Name>
<CAN Multiplexor Signal Name>
<CAN Multiplex Group Name>
<CAN Multiplexed Signal Name>
Signals
<CAN Signal Name>
Fig. 4-11 Display of the CAN IO interface in the WS browser
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
CAN Controller + XCP bypass
• In the tree view, the first hierarchy level (i.e. the one underneath the
ES910) is occupied by the CAN controller.
• The second hierarchy level is occupied by the XCP_on_CAN node (device).
• The third hierarchy level is occupied by folders for rasters and status.
Underneath the folder for rasters , the hierarchy levels are occupied as follows:
– The fourth hierarchy level is occupied by XCP rasters (signal groups).
– The fifth hierarchy level is occupied by XCP signals.
Underneath the Status folder, the hierarchy levels are occupied as follows:
– The fourth hierarchy level is occupied by status signal groups.
– The fifth hierarchy level is occupied by status signals.
ETK interface
• The first hierarchy level is occupied by the ETK bypass device.
Tip
The ETK interface supports hook-based and service-based bypass (V2 and
V3). Both types can be used separately or in parallel.
INTECRIO does not support service-based bypass on an ETK with 8 Mbit/s.
For a hook-based bypass, the levels underneath the bypass device are occupied as follows:
– The second hierarchy level is occupied by the signal groups for sending and receiving.
– The third hierarchy level is occupied by individual signals.
For a service-based bypass, the levels underneath the bypass device are occupied as follows:
– The second hierarchy level is occupied by the signal groups for sending and receiving and by the service points and hooked service points.
The ASAM-MCD-2MC file contains service point descriptions. Number and configurations of the service points actually used in the bypass are determined in the service point selection editor.
– Below the signal groups , the third hierarchy level is occupied by individual signals.
– Below the service points , the third hierarchy level is occupied by the signal groups for sending and receiving.
The available signal groups depend on the settings made in the service point and hooked service point selection editors.
– The fourth hierarchy level is occupied by individual signals.
LIN interface
Tip
Instead of configuring the LIN interface manually, you can import a cluster configuration from a LIN description file.
INTECRIO V4.6 - User’s Guide 73
74
The INTECRIO Components ETAS
• In the tree view, the first hierarchy level (i.e. the one underneath the
ES910) is occupied by the LIN controller.
• The second hierarchy level is occupied by the LIN node (device, LIN I/O).
A LIN node can be used either as master or as slave . The selected node type determines availability and direction of several items below the node level.
• The third hierarchy level is occupied by folders for schedule tables (only available for Master nodes), status display, frames, diagnostic frames, and signals.
Underneath the folder for schedule tables , the hierarchy levels are occupied as follows:
– The fourth hierarchy level is occupied by schedule tables.
– The fifth level is occupied by frames of the various types.
– For unconditional frames , the sixth level is occupied by signals.
– For event-triggered and sporadic frames , the sixth level is occupied by references to unconditional frames.
– For event-triggered and sporadic frames , the seventh level is occupied by references to signals of unconditional frames.
Underneath the folder for status display , the hierarchy levels are occupied as follows:
– The fourth hierarchy level is occupied by status signal groups.
– The fifth hierarchy level is occupied by status signals.
Underneath the folder for frames , the hierarchy levels are occupied as follows:
– The fourth hierarchy level is occupied by folders for event-triggered frames, sporadic frames (only available for Master nodes), and unconditional frames.
– The fifth level is occupied by frames of the various types.
– For unconditional frames , the sixth level is occupied by signals.
– For event-triggered and sporadic frames , the sixth level is occupied by references to unconditional frames.
– For event-triggered and sporadic frames , the seventh level is occupied by references to signals of unconditional frames.
Underneath the folder for diagnostic frames , the hierarchy levels are occupied as follows:
– The fourth hierarchy level is occupied by diagnostic frames (signal groups).
– The fifth hierarchy level is occupied by diagnostic signals.
Underneath the folder for signals , the hierarchy levels are occupied as follows:
– The fourth hierarchy level is occupied by LIN signals of type standard .
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
FlexRay interface
• The first hierarchy level is occupied by the FlexRay IO device (i.e. the
ES920).
• The second hierarchy level is occupied by folders for channels, status display, FlexRay frames, FlexRay PDUs, and FlexRay signals.
Underneath the folder for channels , the hierarchy levels are occupied as follows:
– The third hierarchy level is occupied by two channels.
– The fourth hierarchy level is occupied by slots. Up to 2047 slots can belong to one channel.
– The fifth hierarchy level is occupied by frames. Up to 64 frames can belong to one slot.
– The sixth hierarchy level underneath a frame is occupied by the frame’s
PDUs.
The levels below a PDU are described on page 75.
Underneath the folder for status display , the hierarchy levels are occupied as follows:
– The third hierarchy level is occupied by status signal groups.
– The fourth hierarchy level is occupied by status signals.
Underneath the folder for frames , the hierarchy levels are occupied as follows:
– The third hierarchy level is occupied by FlexRay frames.
– The fourth hierarchy level is occupied by FlexRay PDUs (signal groups).
– The fifth hierarchy level is occupied by simple FlexRay signals and/or
FlexRay signals of type multiplexor .
– Underneath a FlexRay signal of type multiplexor , the sixth hierarchy level is occupied by FlexRay multiplex groups.
– The seventh hierarchy level under the FlexRay multiplex group is occupied by FlexRay signals of type multiplexed .
Underneath the folder for PDUs , the hierarchy levels are occupied as follows:
– The third hierarchy level is occupied by FlexRay PDUs (signal groups).
– The fourth hierarchy level is occupied by simple FlexRay signals and/or
FlexRay signals of type multiplexor .
– Underneath a FlexRay signal of type multiplexor , the fifth hierarchy level is occupied by FlexRay multiplex groups.
– The sixth hierarchy level under the FlexRay multiplex group is occupied by FlexRay signals of type multiplexed .
Underneath the folder for FlexRay signals , the hierarchy levels are occupied as follows:
– The third hierarchy level is occupied by FlexRay signals of type standard .
INTECRIO V4.6 - User’s Guide 75
76
The INTECRIO Components ETAS
ES910 (E-Target)
FlexRay_IO (ES920)
Status status signal groups status signals
Channels channel slot(s)
Frames
+ frame(s)
PDU(s) signal(s) multiplexor signal(s) frame(s)
PDU(s) signal(s)
+ signal(s) multiplexed signal(s) multiplexor signal(s) multiplex group(s) multiplexed signal(s)
Signals signal(s)
Fig. 4-12 Display of the FlexRay interface in the WS browser
Ethernet interface: The Ethernet interface is used to configure an XCP bypass
(XCP on UDP and XETK) or an X/FETK bypass.
For a description of the XCP bypass (XCP on UDP and XETK), see section 4.3.2 on page 57.
X/FETK Bypass
• In the tree view, the first level (i.e. the one underneath the ES910) is occupied by the Ethernet Controller.
• The second hierarchy level is occupied by the X/FETK bypass device.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
• The third hierarchy level is occupied by the service points and hooked service points.
The ASAM-MCD-2MC file contains service point descriptions. Number and configurations of the service points actually used in the bypass are determined in the service point selection and hooked service point selection editors.
• The fourth hierarchy level is occupied by the signal groups for sending and receiving.
The available signal groups depend on the settings made in the service point selection and hooked service point selection editors.
• The fifth hierarchy level is occupied by individual signals.
System interface: The system interface is used to configure the monitoring and display modes of the ES910. Signal groups for the different modes can be activated independently.
• The first hierarchy level is occupied by the system interface device.
• The second hierarchy level is occupied by the signal groups for the different modes.
• The third level is occupied by the individual signals of the different modes.
The signals of a mode are predetermined.
IO interface / Daisychain: An ES4xx/ES63x/ES930 daisy chain can be connected to the IO interface at the back of the ES910. The WS browser in INTECRIO does not display the individual elements of the chain, it displays only the chain as a whole, with one signal group for each chain element and sample period.
Tip
Different from the other interfaces, the daisy chain cannot be configured in
INTECRIO. Instead, an externally created configuration file is imported.
If the configuration file is edited, the changes must be imported, via the
Update context menu, into INTECRIO.
• The first hierarchy level combines the daisy chain and the device.
• The second hierarchy level is occupied by the signal groups for the different sample periods and chain elements.
• The third hierarchy level is occupied by the individual signals assigned to the sample periods and chain elements. The actual signals depend on the daisy chain.
INTECRIO V4.6 - User’s Guide 77
78
The INTECRIO Components ETAS
4.6
RTPRO-PC Connectivity and Hardware Configurator
INTECRIO V4.6 supports the RTPRO-PC target, i.e. a notebook with RTPRO-PC installation. The notebook provides the possibility to connect up to two ES581
CAN interfaces to its USB ports and the possibility to use the notebook’s Ethernet interface for XCP on UDP bypass (with or without XETK) or daisy chain access.
Tip
The RTPRO-PC configuration capabilities of the Hardware Configurator are only available if you installed the INTECRIO-RP package and have an appropriate license key.
INTECRIO
Integration platform (including HC)
INTECRIO-RP
RTPRO-PC Connectivity
*.cod
*.a2l
ES930
PC with RTPRO-PC
(Rapid Prototyping)
ES581
ES63x
ES4xx
...
Fig. 4-13 INTECRIO-RP: RTPRO-PC connectivity
The Hardware Configurator allows the configuration of RTPRO-PC hardware systems to provide real physical signals for inputs and outputs of the model, which can be linked with the software function model in the project configurator (see
section 4.8). The Hardware Configurator is used to configure interfaces available
on the RTPRO-PC target for the experiment. The interfaces do not have to be installed at the time of configuration.
Information about the individual interfaces can be found in section 4.6.2, in the
RTPRO-PC user’s guide and in the ES581 user’s guide.
4.6.1
RTPRO-PC Configuration in the Hardware Configurator
The Hardware Configurator contains the following components required for
RTPRO-PC configuration:
• A framework that provides the basic editor and connections to other
INTECRIO components (e.g. OS configurator, project integrator, ETAS
Experiment Environment).
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
• A specific expansion of the basic editor for each interface supported by
INTECRIO. Each of these expansions allows for the configuration of the respective interface based on parameters that are displayed in various tabs.
• A generator for the configuration of the device drivers.
These components can be used for the following tasks:
• Configuring interfaces (or loading a daisy chain or CAN configuration)
• Assigning input or output actions for operating system tasks (defined in the OS configurator)
• Providing conversion formulas for describing the mapping of physical signals (model view) to raw values (driver view)
The hardware system is displayed in the WS browser as a tree structure. The
RTPRO-PC system itself is located in the
Hardware/Hardware Systems folder on the top level, the simulation controller (
X86 (RTPRO-PC Target)
) is shown on the level directly underneath it. This is the master with which all other interfaces are linked as slaves. The available hardware signals are placed in a lower hierarchy level. Each level has parameters that can be adjusted in appro-
priate editors. Their appearance is shown schematically in Fig. 4-6.
The entry (e.g., controller, device, signal group, signal) to be edited is selected in the WS browser, while the corresponding editor is opened in the display window. It is possible to edit several objects at the same time.
The editor lists all parameters of the respective object in tables on one or more tabs. Number and names of the parameters and tabs depend on the object.
Manual Configuration: In offline mode, the Hardware Configurator allows the configuration of the interfaces supported by INTECRIO to build a hardware system. The following points must be observed when the board hierarchy is created:
• One hardware system can contain only one RTPRO-PC target.
• A hierarchy consists of a simulation controller as master and one or several slave interfaces controlled by the master.
• Only one simulation controller (
X86 (RTPRO-PC Target)
) can be selected as master for a configuration.
• All slave interfaces are located on the same hierarchy level; a slave interface cannot have its own slave interfaces.
• Each slave interface is assigned to its master.
INTECRIO V4.6 - User’s Guide 79
80
The INTECRIO Components ETAS
• Some interfaces can be present several times in an RTPRO-PC system. Tab.
4-5 lists the available numbers of interfaces.
ES581
(CAN_IO or
XCP_on_CAN)
Daisychain
(IO interface) via Ethernet
XCP_on_UDP via Ethernet
RTPRO-PC Remarks
0 – 2 Each ES581 supports up to two CAN controllers.
Each CAN controller supports either one
CAN_IO device or one XCP_on_CAN device.
4 is the maximum number of all XCP interfaces, i.e. XCP_on_CAN and XCP_on_UDP.
0 – 1 A chain of ES4xx and/or ES63x and/or
ES930 modules.
0 – 4
See section 4.3.2 on page 57 for details.
4 is the maximum number of all XCP interfaces, i.e. XCP_on_CAN and XCP_on_UDP.
Tip
INTECRIO supports XETK on RTPRO-PC systems. XETK is supported via the XCP on UDP configuration, i.e. using an Ethernet controller with XCP device in the INTECRIO hardware configuration. To connect the XETK hardware, the Ethernet interface of the RTPRO-PC notebook is used.
See the INTECRIO online help for details on XETK configuration.
Tab. 4-5 Number of interfaces/elements per RTPRO-PC system
• For the ES581 CAN interfaces, it must be ensured that each ES581 features a unique ID.
• Interfaces of different types can be used with a master.
Tip
During insertion, the Hardware Configurator offers a list with objects that may be inserted at the current location of the tree view.
Interfaces, devices and other sublevels can be inserted in the hierarchy, and deleted when these points are taken into account.
The interfaces, devices, signal groups and signals of the hardware system can be configured in the Hardware Configurator. The following points must be observed during the configuration:
• While a series of interface parameters are preset, the tasks and processes associated with the signals/signal groups are defined in the OS configurator. All signals of a signal group are processed at the same time.
• An implementation (i.e. a conversion formula and a valid value range) can be specified for CAN signals. The following formulas are available:
– Identity:
– linear: f(phys) = phys f(phys) = a/b *phys + d/c
• Up to four CAN controllers can be configured in the same RTPRO-PC hardware system.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
• Up to four XCP devices (XCP_on_CAN or XCP_on_UDP) can be configured in the same RTPRO-PC hardware system.
Parts of the hardware system can be copied via Copy and Paste . The settings of the target parts are overwritten; if no target part is selected, a new one is created.
Import: As an alternative to manual configuration, it is possible to import a hardware description (
*.hwx
file); see "HWX Import" on page 57.
4.6.2
Interface Types and Supported Interfaces
Tab. 4-6 contains the interface classes for the RTPRO-PC target and the names of
the interface supported by INTECRIO.
Interface class
Simulation controller
Communication interfaces
IO interface
Name
X86
(RTPRO-PC Target)
ES581 +
CAN_Controller +
CAN_IO
ES581 +
CAN_Controller +
XCP_on_CAN
Description system controller
CAN IO interface
XCP bypass on CAN
Ethernet_Controller Interface for XCP bypass on UDP and daisy chain.
Daisychain A chain of ES4xx and/or ES63x and/or
ES930 modules; connected to the
Ethernet controller.
Tip
The RTPRO-PC target has only one Ethernet interface. You need an Ethernet switch to use a daisy chain and XCP on UDP simultaneously.
Tab. 4-6 Interface classes of the RTPRO-PC target and names of supported interfaces/elements
Tab. 4-5 on page 80 indicates how many interfaces of a type can be used with
one RTPRO-PC hardware system.
INTECRIO V4.6 - User’s Guide 81
82
The INTECRIO Components ETAS
Fig. 4-14 shows the schematic structure of the interfaces in the WS browser.
RTPRO_PC
X86 (RTPRO-PC Target)
Board
Controller
Device
(further levels)
Fig. 4-14 Display of the RTPRO-PC interfaces in the WS browser
Simulation controller:
The simulation controller (X86 in Fig. 4-14) is
equipped with an Ethernet interface (the Ethernet interface of the RTPRO-PC notebook) for XCP on UDP and XETK, and an interface to the CAN bus of the vehicle.
Communication interfaces: Communication interfaces are used for distributing messages on the network (such as the CAN bus). The display of supported communication interfaces in the Hardware Configurator varies so much that all are described below.
ES581 + CAN Controller + CAN IO
• In the tree view, the first hierarchy level (i.e. the one underneath the X86) is occupied by the ES581 board.
• The second hierarchy level is occupied by the CAN controller.
• The third hierarchy level is occupied by the CAN IO device.
• The fourth hierarchy level is occupied by folders for CAN frames (signal groups) and CAN signals.
Underneath the folder for CAN frames , the hierarchy levels are occupied as follows:
– The fifth hierarchy level is occupied by CAN frames (signal groups).
– The sixth hierarchy level is occupied by simple CAN signals and/or CAN signals of type multiplexer .
– Underneath a CAN signal of type multiplexor, the seventh hierarchy level is occupied by CAN multiplex groups.
– The eighth hierarchy level under the CAN multiplex group is occupied by CAN signals of type multiplexed .
Underneath the folder for CAN signals , the hierarchy levels are occupied as follows:
– The fifth hierarchy level is occupied by CAN signals of type standard .
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
X86
(RTPRO-PC Target)
ES581
CAN_Controller
CAN_IO
Frames
<Signal Group Name>
<CAN Signal Name>
<CAN Multiplexor Signal Name>
<CAN Multiplex Group Name>
<CAN Multiplexed Signal Name>
Signals
<CAN Signal Name>
Fig. 4-15 Display of the ES581 CAN IO interface in the WS browser
ES581 + CAN Controller + XCP bypass
• In the tree view, the first hierarchy level (i.e. the one underneath the X86) is occupied by the ES581 board.
• The second hierarchy level is occupied by the CAN controller.
• The third hierarchy level is occupied by the XCP_on_CAN device.
• The fourth hierarchy level is occupied by folders for rasters and status.
Underneath the folder for rasters , the hierarchy levels are occupied as follows:
– The fifth hierarchy level is occupied by XCP rasters (signal groups).
– The sixth hierarchy level is occupied by simple XCP signals.
Underneath the Status folder, the hierarchy levels are occupied as follows:
– The fifth hierarchy level is occupied by status signal groups.
– The sixth hierarchy level is occupied by status signals.
Ethernet interface (XCP on UDP and XETK):
INTECRIO V4.6 - User’s Guide 83
84
The INTECRIO Components ETAS
IO interface / Daisy Chain: An ES4xx/ES63x/ES930 daisy chain can be connected to the Ethernet port of the RTPRO-PC target. The WS browser in INTEC-
RIO does not display the individual elements of the chain, it displays only the chain as a whole, with one signal group for each chain element and sample period.
Tip
Different from the other interfaces, the daisy chain cannot be configured in
INTECRIO. Instead, an externally created configuration file is imported.
If the configuration file is edited, the changes must be imported, via the
Update context menu, into INTECRIO.
• The first hierarchy level contains the Ethernet controller.
• The second hierarchy level contains the daisy chain device.
• The third hierarchy level is occupied by the signal groups for the different sample periods and chain elements.
• The fourth hierarchy level is occupied by the individual signals assigned to the sample periods and chain elements. The actual signals depend on the daisy chain.
4.7
PC Connectivity
INTECRIO
Integration platform (including HC)
INTECRIO-VP
PC Connectivity
*.cod
*.a2l
PC
(Virtual Prototyping)
Fig. 4-16 INTECRIO-VP: VP-PC connectivity
With its PC connectivity, INTECRIO-VP offers the possibility to use INTECRIO for virtual prototyping purposes, i.e. validation and pre-calibration of application software. The possibility to verify and validate software as early in the V cycle as possible is the main motivation for virtual prototyping.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
INTECRIO-VP provides the functionality required for virtual prototyping with
INTECRIO. This means in detail:
• Providing the VP-PC target. This target can be selected in the WS browser just like ES1000 or ES900 or RTPRO-PC.
• The possibility to execute models with adaptive simulation time (i.e. the shortest possible computation time given the computational power and the complexity of the model).
• The possibility to configure the RTA-OSEK for PC operating system in the
• The possibility to generate executable file and ASAM-MCD-2MC descrip-
tion just as for rapid prototyping (see section 4.10).
• The possibility to use RTA-TRACE and INCA-EIP in the virtual prototyping experiment. This includes the VP service, available in the Windows task bar.
• The possibility to use back animation of ASCET and M ATLAB /Simulink models during the virtual prototyping experiment.
Back animation means that the model variables can be displayed on the
BMT display devices and that calibration variables can be calibrated directly from within the model.
• The possibility to connect to a Microsoft ® Visual Studio ® debugger during the virtual prototyping experiment. The table lists the versions you can use.
Version
2008
2010
Edition
Professional Express
X
X
X
–
Tab. 4-7 Supported (X) and unsupported (–) Microsoft Visual Studio versions
The debugging possibility is limited to the following use case: Build process and experiment are performed on the same workstation, and the experiment is started immediately after the build process.
Tip
You can either use back animation in a virtual prototyping experiment or connect the virtual prototyping experiment to a debugger, but not both.
In order to simulate interrupts in a virtual ECU, the virtual machine has to manipulate the stack of the application thread asynchronously. Since many functions cannot cope with asynchronous stack changes, stepping is not possible in every line of code.
Tip
It is recommended that you set multiple breakpoints and jump from breakpoint to breakpoint. For further details, see the RTA-OSEK for PC user’s guide, section 16.2.
INTECRIO V4.6 - User’s Guide 85
86
The INTECRIO Components ETAS
4.8
The Project Configurator
Sensor/ actuator signal
INTECRIO integration platform
Module interface
Interface for integrating software components
OS Configurator
Configuration of
OSEK operating system
HC
Documentor
Project Configurator
Network list of functions and modules
Project Integrator
Fundamental build process for the project integration
Function net list
Fig. 4-17 The project configurator
The project configurator is part of the integration platform of INTECRIO. It is used to specify software systems and system projects. It contains a graphical editor (on
the right in Fig. 4-17) that can be used in offline and online mode.
4.8.1
Offline Mode
In offline mode , modules and AUTOSAR software components (SWC) can be displayed, and functions, software systems and system projects can be created and configured.
Modules and SWC
Software\Modules or
Environment\Modules
.
In the graphical editor of the project configurator, modules/SWC are represented as blocks, together with the name of the module.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
The signal sinks or inputs are arranged on the left side of the block, the signal sources or outputs on the right side. The color denotes either the BMT used to create the module (defaults: light red – M ATLAB /Simulink, green – ASCET, dark red – AUTOSAR SWC) or the usage as environment module (slightly different green).
(a) (b)
(c)
(d)
Fig. 4-18 Standard layout of a module/SWC
(a: Simulink module, b: ASCET module, c: AUTOSAR SWC, d: environment module)
The standard size of the block is designed so that all interface elements are visible. The names of the signal sources and sinks are abbreviated, if required; complete names appear as tooltips.
The color of the block can be adjusted; SWC/modules created with the same
BMT always have the same color. Size and layout of each block can be adjusted individually.
If the description of the module is updated by importing a new version of the
SCOOP-IX file, all user settings are retained.
Functions
Functions (see also the section "Functions" on page 31) are created in the proj-
ect configurator and placed in the folders
Software\Functions
or
Environment\Functions
in the workspace. Their names can be randomly selected.
The interface of a function – signal sinks, signal sources – is also created in the project configurator. Implementations, signal type, etc., are adopted by the elements that are connected to the inputs and outputs.
The standard layout for the external view of a function is designed just like that of a module/SWC: the signal sinks of the function are arranged on the left side, signal sources on the right side. The icons are derived from the connected module/SWC ports. The block size is selected automatically, according to the number of signal sinks and sources. The size of the function and the positions of the signal sinks and sources on their respective sides can be adjusted.
(a) (b)
Fig. 4-19 Standard layout (external view) of a function (a) and environment function (b)
INTECRIO V4.6 - User’s Guide 87
88
The INTECRIO Components ETAS
Any number of modules can be assigned to a function, but each module only once. This restriction notwithstanding, a module can appear more than once in the graphical display of a function. Other functions cannot be assigned to a function.
The interface elements of the modules can be connected with each other in the graphical editor or the connection wizard of the project configurator or with interface elements of the function. Unused module interface elements can be removed from the graphical representation (not from the module). The following rules apply to the connections:
• Modules : A source (output) can be connected with any number of sinks
(inputs).
A sink (input) can be connected with exactly one source (output).
• SWC : A sender can be connected with several receivers, a server can be connected with several clients.
Scalar senders and receivers with primitive typization can be connected with inputs and outputs of modules.
• Disconnected sources and sinks are allowed.
• A connection between modules can be either static or dynamic. Dynamic connections can be changed during the runtime of the program. For
SWC, only static connections are possible.
Software Systems and Environments
Software systems (see also the section "Software Systems" on page 32) and
environment systems are created in the project configurator and placed in the
Software\Software Systems
or
Environment\Environment Systems
folder in the workspace. Their names can be randomly selected.
The interface of a software or environment system is created the same way as
the interface of a function (see "Functions"). The standard layout of a software
or environment system corresponds to that of a function. The block size is selected automatically, according to the number of signal sinks and sources. The size of the software or environment system and the positions of the signal sinks and sources on their respective sides can be adjusted.
(a) (b)
Fig. 4-20 Standard layout of a software system (a) and environment system (b)
Any number of modules, SWC or functions can be assigned to a software or environment system. For assignment and connection, the following applies:
• In INTECRIO, modules and SWC cannot be multiply instantiated, i.e. each module or SWC can be used only once in a particular software or environment system. If several functions containing the same module/SWC are inserted in a software or environment system, the code generation issues an error message. The same happens if a module/SWC is inserted into a
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components software or environment system both directly and as part of a function.
This restriction notwithstanding, a module/SWC can appear more than once in the graphical display of a software or environment system.
• Modules, SWC and functions can be used either for software systems or for environment systems. It is not possible to use a module/SWC/function imported/created for a software system in an environment system, and vice versa.
System Projects
Similar to functions and software or environment systems, system projects (see
also "System Projects" on page 34) are created and configured in the project
configurator. A system project can be assigned a hardware system, a software system, and an environment system (i.e. any number of modules and functions).
In the graphical editor, software system, environment system and each hardware device are displayed as separate blocks. Unused signals can be removed from the graphical representation.
Fig. 4-21 System project in the graphical editor
The required connections between the signal sources and sinks of hardware and software must be created by the user. The same rules apply as for the connec-
tions within a function (see page 88), expanded to software and hardware com-
ponents.
The size of the hardware blocks and the positions of the signal sinks and sources on their respective sides can be adjusted.
A workspace can contain several system projects. The user can activate only one system project at a time. For each system project, build options can be set that affect the creation of the executable file. If the build process is invoked not from the context menu of a system project, but from the menu or the toolbar, it uses the active system project.
INTECRIO V4.6 - User’s Guide 89
90
The INTECRIO Components ETAS
4.8.2
Online Mode
Dynamic connections can be changed in online mode , i.e. during the running experiment. In general, changes are allowed that do not lead to a change in structure. Changes to the description or display of modules, functions or software systems (e.g. removing or adding signal sources/sinks, modules or functions) are not possible in online mode.
The implementation characteristic of the newly connected signal sources and sinks is adjusted via changes in the copying process on the target. A conversion is performed in the case of different value ranges or quantizations. The value assignment to the signal sink is always limited; this limitation cannot be deactivated.
The mechanism for editing connections is the same as in the offline mode. In addition, the online mode offers the option of connecting a stimuli signal with a signal sink.
4.9
The OS Configurator
INTECRIO integration platform
Module interface
Interface for integrating software components
OS Configurator
Configuration of
OSEK operating system
Project Configurator
Network list of functions and modules
Project Integrator
Fundamental build process for the project integration
HC
Documentor
OIL file
Fig. 4-22 The OS configurator
The configuration of the operating system is a very important task in the context of creating a real-time prototype. Inside of INTECRIO, this task is handled by the
OS configurator (another component of the integration platform).
Section 4.9.1 provides an overview of the tasks of the operating system,
section 4.9.2 describes the OS configurator.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
4.9.1
Tasks of the Operating System
The OSEK consortium 1 (see http://www.osek-vdx.org/ ) developed standards for the real-time operating systems used in the automobile industry, among them the OSEK implementation language OIL. An operating system that meets the
OSEK standards is referred to as OSEK operating system.
The system controller boards ES1130 and ES1135 use the OSEK-compatible operating system ERCOS EK V4.3. For work with AUTOSAR 2 , an addition to
ERCOS EK V4.3 exists which is installed with INTECRIO V4.6. The ES910 and
RTPRO-PC use the OSEK-compatible and AUTOSAR-compatible operating system RTA-OSEK, the PC uses, in case of virtual prototyping, RTA-OSEK for PC.
OSEK operating systems support the coordinated execution of many processes and—when using AUTOSAR—runnable entities (RE). On systems with a single
CPU, different processes/RE cannot be executed at exactly the same time since the CPU is capable of executing only one instruction at a time. For this reason, the operating system is responsible for performing a quasi-parallel processing or multitasking. That is, the operating system determines the processing sequence of the tasks and processes/RE that compete for the processor and, if necessary, toggles between the executions of different tasks.
Scheduling
Scheduling is a core function of an OSEK operating system. The scheduler must decide which process is started first from a group of activated processes/RE. The decision strategy, the so-called scheduling algorithm , is very important since it affects the real-time capabilities and the efficiency of the system. To meet the strict requirements of efficiency and real-time behavior, OSEK operating systems use a combination of static and dynamic scheduling, together with a combination of cooperative and preemptive scheduling.
Static scheduling: For static scheduling , the scheduling algorithm has all the information about the processes/RE to be scheduled and their limitations. Custom limitations are calculation time, deadline, future execution times, priority relationships and mutual exclusion. Since all limitations of the processes and RE are known before the system starts, it is possible to determine the processing sequence of these processes/RE up front (offline). If such an offline schedule exists, it is sufficient to start the processes/RE at runtime at the predefined times in the predefined order.
Dynamic scheduling: For dynamic scheduling on the other hand, the algorithm only knows the activated processes/RE and does not have any knowledge of future activations. Since new processes/RE can be activated spontaneously, the scheduler must determine at runtime which one of the processes/RE must be selected.
The advantage of dynamic scheduling over static scheduling lies in the flexibility with which external events can be addressed. In particular, the effectiveness of static scheduling decreases with decreasing latency period. Disadvantages of dynamic scheduling are higher demands on the computing power and need for
1. Working group for Open Systems and their Interfaces for Electronics in Motor
Vehicles (German: O ffene S ysteme und deren Schnittstellen für die E lektronik im K raftfahrzeug)
2. Aut omotive O pen S ystem Ar chitecture, see http://www.autosar.org
INTECRIO V4.6 - User’s Guide 91
92
The INTECRIO Components ETAS increased memory for managing the processes/RE. Since dynamic as well as static scheduling are supported, OSEK operating systems allow for the application of combined strategies which were optimized with respect to the demands concerning response time and memory capacity.
Tasks
An operational sequence or Task is defined as the result of static scheduling. It contains a sequence of processes or RE that must be executed in the specified order and with a defined priority if a certain activation event occurs.
Task p1
A p2
A p3
A p4
A
Time
Processes
Fig. 4-23 Task scheme
Dynamic task scheduling (or multitasking) only applies to tasks as a whole, not the individual processes/RE. Within a task, the scheduler does not have to make a decision since the processing sequence is statically specified. This reduces the required computing power at runtime and the memory requirement since it is not necessary to manage a high number of processes/RE but only a much smaller number of tasks.
Each task is assigned a static priority . Tasks activated at runtime are handled according to their respective priority. A task with a higher priority takes precedence over a task with a lower priority. Different tasks can have the same priority. If these tasks are scheduled for execution at the same time, they are arranged in a FIFO queue and processed based on the principle "First come, first served."
Dynamic scheduling is handled in accordance with a status model for the tasks.
Upon activation, a task is changed to the status activated . If its priority is higher than that of the running task and if switching is possible, it is started (the latter translates to a direct transition from the status "inactive" to the status "running") while the execution of the current task is interrupted (the task is changed to the status "activated"). At the end of the running task, i.e. when it changes to the status inactive , the activated task with the highest priority and at the first
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components position of the respective FIFO queue is started or continued (if this task was
previously interrupted). Fig. 4-24 shows the existing task states and all possible
transitions.
Activated
Interrupt
Activate
Start
Running
Start
Terminate
Inactive
Fig. 4-24 Task states and transitions
Cooperative and Preemptive Scheduling
There are two possible methods for switching between a running task and an activated task with higher priority. The first switches the execution at predefined locations of the software. These predefined locations are the boundaries between the processes/RE of a task. Since the task with the higher priority is waiting until the running process/RE finishes, this method is referred to as cooperative scheduling
Priority
Activate task B
Start task B
Task B p1
B p2
B p3
B p4
B p5
B
Task A p1
A p2
A p3
A p4
A
Time
Fig. 4-25 Cooperative scheduling
Tip
Cooperative scheduling is supported only by the ERCOS EK operating system; it is therefore available only for ES1000 rapid prototyping applications.
The advantage of cooperative scheduling is the efficient utilization of resources.
The design ensures that access to resources, such as stack, register or messages, is exclusive. In addition, there is no need to secure the process/RE context when switching takes place; all processes/RE can be executed using the same register bank. The disadvantage of cooperative scheduling is the relatively slow response time that is dependent upon the longest execution time of the processes/RE.
The second strategy– preemptive scheduling –allows for switching the execution inside the processes/RE at the boundaries of machine instructions (provided that the interrupts are not deactivated).
INTECRIO V4.6 - User’s Guide 93
94
The INTECRIO Components ETAS
The scheduler is, therefore, capable of interrupting the currently running process/RE of a task and starting the execution of a task with higher priority (see
Priority
Activate task B
Start task B
Task B p1
B p2
B p3
B p4
B p5
B
Task A p1
A p2
A p2
A p3
A p4
A
Interruption ...
… Continuation of p2
A
Time
Fig. 4-26 Preemptive scheduling
External events (interrupts) and periodic activations with controlled variations require short response times. Preemptive scheduling can meet these requirements. The disadvantage of preemptive scheduling is higher memory capacity since it is necessary to secure the context of interrupted processes/RE and ensure data consistency.
Preemptive scheduling also offers flexibility for handling external events or interrupts . It is possible to assign an interrupt source to a priority level, thereby starting the task with a very fast response time. This mechanism is represented by the direct transition from the status inactive to running
The tasks called by the occurrence of interrupts and planned by the interrupt controller are referred to as hardware tasks .
Preemptive and cooperative tasks have different priority ranges that do not overlap. Preemptive tasks always have a higher priority than cooperative tasks.
preemptive tasks
0 cooperative tasks
0
Fig. 4-27 INTECRIO – Priority scheme
Data Consistency with Preemptive Scheduling
In preemptive scheduling, it is possible that a process or RE with low priority is interrupted by a process/RE with higher priority. If the interrupted process/RE reads a variable and the interrupting process/RE describes the same variable,
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components inconsistencies may occur if the interruption occurs between to successive read
operations as illustrated in Fig. 4-28. The diagram shows what happens of the
program code is interrupted during the processing and no resource protection is implemented.
Priority x = 2
Task B p1
B
p2
B
x = -1
Task A p1
A if(x < 0) {y = -x}
p1
A
{y = -x}
y = 1 y = -2
Data inconsistency
Fig. 4-28 Data inconsistency
Process p1
A
of task A calculates the absolute value of x
: if (x<0)
Time
{y = -x;} else
{y = x;}
Process p1
A
reads the input value
-1
. The condition of the first line of the algorithm is met, so that the assignment y = -x
is scheduled for execution. Before the assignment can be executed, process p1
A
B assigns x
the value of
2
. If p1
A
is interrupted. Process p2
B
of task
is taken up again after the end of task B, the algorithm uses the pending assignment y = -x
and the new value x = 2 instead of x = -1
, i.e. p1
A
furnishes an incorrect result:
|-1|
≠
2
.
This is merely a simple example to illustrate data inconsistency; however, in a real application, data inconsistency can lead to a system crash.
The correctness of the system therefore depends on the time sequence and the order of interruptions in the system. To avoid system and timing-dependent software errors, data consistency must be guaranteed.
Tip
For the time between start and termination of a process P1 or RE R1, it must be ensured that all data stored in memory accessed by P1/R1 may change their value if and only if they are changed by P1/R1.
Messages: To solve the problem of data consistency, the messages concept is
supported by the crossbar (cf. section 2.5.5). These are protected global vari-
ables. The protection is achieved by working with copies of the global variables.
The system analyzes whether a copy is required and ensures an optimum data consistency scheme without detrimental effects on the core of the runtime.
INTECRIO V4.6 - User’s Guide 95
96
The INTECRIO Components ETAS
While a process is being started, all input messages in its private area are copied for message copies. After the process is finished, all output messages that are located in the private area as copies, are copied into the global message area.
The operating principle of messages is represented in Fig. 4-29.
Priority msg x = -1 msg x = 2
Task B msg(1) x = -1 p1
B
p2
B
msg(1) x = -1
Task A p1
A if(x < 0)
p1
A
{y = -x}
y = 1
Time
Fig. 4-29 Handling of messages
At the start, process p1
A
of task A copies the incoming message msg
to the private message copy msg(1)
. All subsequent read operations to the message access this private copy. Although process p1
A
is interrupted by task B, which sets the value of msg
from
-1
to
2
, this change does not affect process p1
A ensures that process p1
A cution time. This ensures the data consistency since the algorithm
. This
works with the private copy throughout the entire exeif (x<0)
{y = -x;} else
{y = x;} is correctly executed in any case.
When working with AUTOSAR SWC, an AUTOSAR runtime environment (RTE,
cf. section 3.2) is used instead of the crossbar. If necessary, the RTE uses suitable
means of the OS (resources, interrupt blocks) to ensure consistency of the transmitted data.
Application Modes
Application Modes were developed to support different runtime configurations of the complete system at different times. They allow for a simple and flexible design and the management of system statuses of completely different functions. Examples of such application modes are Startup , Normal Operating Mode ,
Shutdown , Diagnosis and EEPROM Programming . Each application mode can be equipped with its own tasks, priorities, timer configurations, etc.
Tip
RTA-OSEK (ES900) supports only one application mode. To grant compatibility, only one application mode is allowed in INTECRIO even when working with
ERCOS EK and the ES1000.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
An application mode consists of two successive phases: an initialization and a normal sequence phase. During initialization, all interrupts are deactivated. This is used, for example, for the set-up of hardware registers and variables. At the end of the phase, interrupts are activated and the normal processing of the tasks begins.
4.9.2
Design of the OS Configurator
The design of the OS configurator of INTECRIO is shown in Fig. 4-30.
OSC editor
OIL interface
*.oil
,
*.esc
ERCOS EK ,
RTA-OSEK,
RTA-OSEK for PC
Configurator/generator
(e.g. ESCAPE)
Connection to other OSEK operating systems is possible
*.c
,
*.h
Compiling
Operating system
OS libraries
PC
Experimental
Target
Fig. 4-30 OS configurator: Design
The figure replicates the process sequence during the configuration of the operating system.
The OSC editor is an easy to handle editor that provides the user with a quick overview of the system and allows for editing the configuration in an applicationoriented display.
After completed configuration, the OIL interface creates the required configuration files in the OIL language (
*.oil
files).
INTECRIO V4.6 - User’s Guide 97
98
The INTECRIO Components ETAS
However, only the OSEK conformance classes BCC1 and BCC2 are directly supported. The OIL configuration files can be processed further with any OSEK operating system. The further processing in INTECRIO is based on the operating systems ERCOS EK , RTA-OSEK or RTA-OSEK for PC of ETAS.
The configurator/generator generates C-code files from the
*.oil
files which, in turn, are used to compile the operating system while linking the operating system library. Only the completed operating system is loaded onto the experimental target, all previous levels are executed on the PC.
4.9.3
The OSC Editor
INTECRIO Vx.y
File Edit View ...
Software
Hardware
System
Sys1
Target
CPU1
OS
SWSys
…
Sys1 - Target - CPU1 - OS Configuration
OS
AppMode
Task1
Actions
Event
Task2
Init
Exit
ISRs
Software Tasks
Software
Function1
Module1
Processes
Process1
Process2
...
Software
Environment Hardware
Priority
Period
...
5
600
The interface of the OSC is divided into three parts: The top left field contains the
OS configuration view, at the top right are three tabs that show the hierarchical structures of software, environment and hardware system. You can select whether the tabs show all processes or only those that are not assigned to a task.
Below these two fields if the input field for the attributes of the object selected in the OS configuration view. The attributes relevant for the object and the operating system are shown.
The OSC has two modes:
• Offline Mode
• Offline mode
The operating system is configured in offline mode. The minimal priority of preemptive tasks can be set for the operating system. It can also be defined whether tracing the runtime behavior should be handled using the tool RTA-TRACE (global or on the process level).
For ASCET models, you have the additional option to configure the OS in
ASCET, and then import the configuration (
*.oil
file) into INTECRIO.
• Online mode
In online mode, i.e. with running experiment, the setting options of the
OSC are blocked. You can use the OS configurator only as display.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
Creating Tasks
The operating system is located on the top level of the OS configuration view.
With AUTOSAR SWC: No application mode is shown in the display. One Init and Exit task each are automatically created directly below the operating system.
In addition, tasks can be created in the
Software Tasks
folder. The type of these tasks is defined by the assigned runnable entities.
-
OS
-
AppMode
1
+
Timer task
+
+
Init task
Exit task
+
-
ISRs
1
(RTA-OSEK only)
Software Tasks
2
+
Software task
3
Fig. 4-31 OSC: Tree structure
(1: not for AUTOSAR SWC, 2: with AUTOSAR-SWC:
Tasks
, 3: with
AUTOSAR SWC: task type defined by assigned RE)
Without AUTOSAR SWC:
The application mode (see page 96) is created
directly below the operating system.
Tip
On principle, the ERCOS EK operating system allows for several application modes with their own Init tasks. However, since RTA-OSEK does not offer this, it is generally omitted here.
The tasks of type Timer are created on the next level below the application mode.
One Init and Exit task each are automatically created directly below the operating system; they are used by all application modes. In addition, tasks of type Software can be created in the
Software Tasks
folder. When working with RTA-
OSEK, you can also create interrupt service routines in the
ISRs
folder. The task
types are explained in Tab. 4-8.
INTECRIO V4.6 - User’s Guide 99
100
The INTECRIO Components ETAS
The possible task types have the following meaning:
Timer These tasks are periodically activated. They can have different periods.
Timer tasks activated via an alarm (see page 102) are executed auto-
matically at the initialization of the application mode.
Software These tasks are non-periodically activated via commands of the operating system or via certain events.
Init Automatically created task that is executed once when an application mode is executed. Interrupts are deactivated during the runtime of the task.
Exit
ISR
Automatically created task that is executed once at the end of the simulation. Interrupts are deactivated during the runtime of the task.
Interrupt service routines (RTA-OSEK only).
Tip
The RTA-OSEK operating system does not support init/exit tasks. In that case,
INTECRIO automatically generates code that calls these tasks at the start or end of an application mode via C function calls.
Tab. 4-8 Task types
Below the application mode, timer tasks can be created, deleted and renamed.
Each task features the folders
Actions
and
Event
for processes and events.
Tip
For virtual prototyping (target PC), the
Event
folder is omitted.
-
AppMode
-
Task_1
+
Actions
+
Event
+
Task_2
+
. . .
Task_3
Fig. 4-32 OSC: Application mode with assigned timer tasks
Software tasks can only be created in the
Software Tasks
folder. These tasks do not belong to any application mode and are not included in the scheduling of the operating system. They can still be called during an experiment, e.g. with an
ERCOS EK call or an event from the Hardware Configurator.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
Interrupt service routines (ISRs) can only be created in the
ISRs
folder. The ISR sequence has no influence on the runtime behavior.
-
OS
+
+
+
-
-
AppMode
Init task
Exit task
ISRs
-
. . .
ISR
+
Actions
. . .
Software Tasks
-
+
Software task
Interrupt
+
+
Actions
Event
Fig. 4-33 OSC: Software task and ISR (Neither ISRs nor events exist for virtual prototyping. The respective folders are omitted in that case.)
Task Properties
The properties of timer and software tasks can be edited. In case of incorrect entries, warnings or error messages are issued, and the old value is kept.
Tip
The properties of the Init and Exit tasks cannot be edited. For ISRs, only the priority can be edited.
With AUTOSAR SWC:
• Priority
The activation of tasks is determined by their priority if several tasks are scheduled for execution at the same time. Tasks are interrupted if a task with a higher priority than the currently running task is activated.
Possible minimum and maximum values depend upon the target as well
as the scheduling; Fig. 4-34 on page 102 shows the scheme of possible
values.
• Maximum number of simultaneous activations (Task Activation)
This value determines how often a task can be activated for scheduling. If a task is activated again before the execution is finished after its previous activation, the task is then activated twice. To save system resources, the number of simultaneous activations can be limited.
INTECRIO V4.6 - User’s Guide 101
102
The INTECRIO Components ETAS
Without AUTOSAR SWC:
• TaskID
Unique number as identifier.
• Priority
The activation of tasks is determined by their priority if several tasks are scheduled for execution at the same time. For example, if several periodic tasks were scheduled for simultaneous activation, the task with the highest priority is executed first. Tasks are interrupted if a task with a higher priority than the currently running task is activated.
Possible minimum and maximum values depend upon the target as well
as the scheduling; Fig. 4-34 shows the scheme of possible values.
max. interrupt priority
Hardware
Tasks (ISR)
min. interrupt priority max. priority (software/periodic)
Software and periodic tasks
min. preemptive priority max. cooperative priority
0
Software and periodic tasks
0
min. cooperative priority
Fig. 4-34 Priority scheme
Tip
Although ERCOS EK supports a priority overlap of periodic/software tasks and hardware tasks (ISRs), INTECRIO V4.6 does not use this feature, to make configuration as easy as possible.
RTA-OSEK supports only preemptive scheduling.
• Period
It determines after what time in seconds the task is activated again.
This option is only available for timer tasks.
• Timebase (ERCOS EK /ES1000 only)
Here, the selection is made whether activation is carried out by means of an alarm or a timetable.
This option is only available for timer tasks.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
• Delay
The task is activated for the first time after the time in seconds defined in this option. If the delay value is 0, the task is activated as soon as the program starts, and afterwards at the beginning of every period.
Period
Task
Delay
Time
Fig. 4-35 Delay of a task
This option is only available for timer tasks.
• Deadline (ERCOS EK /ES1000 only)
This value indicates the maximum difference in seconds between the activation of the task and the end of the execution.
• Execution Budget (RTA-OSEK/ES900, RTA-OSEK/RTPRO-PC and RTA-OSEK for PC/PC only)
This value contains the maximum execution time (in seconds) of a task.
Values between 0.000001 s and 128 s are permitted; the value 0 disables runtime monitoring.
• Maximum number of simultaneous activations (Max. number of activation)
This value determines how often a task can be activated for scheduling. If a task is activated again before the execution is finished after its previous activation, the task is then activated twice. To save system resources, the number of simultaneous activations can be limited.
• Monitoring
This option determines whether monitoring information is collected for this task (
True
) or not (
False
). If the option is activated, additional signal sources, e.g. for the entire runtime of the task, are created. These signal sources are part of the ASAM-MCD-2MC description and can be measured in the ETAS Experiment Environment or in INCA.
INTECRIO V4.6 - User’s Guide 103
104
The INTECRIO Components ETAS
If monitoring is enabled, the following monitoring variables are created for each task:
Variable Meaning actTime startTime maxRunTime dT
Activation time of the task
Start time of the task grossRunTime
Total runtime of the task netRunTime minRunTime
Net runtime of the task
Minimum runtime of the task
Maximum runtime of the task
Time difference between the last and the current activation of the task
The monitoring variables are measured in systems ticks. They must be converted to seconds for the user.
• Exclude from Tracing (RTA-OSEK/ES900, RTA-OSEK/RTPRO-PC and
RTA-OSEK for PC/PC only)
This option determines whether a task is excluded (
True
) from monitoring with RTA-TRACE or not (
False
).
Setting Up Timer and Software Tasks
Finally, the processes/RE available in the modules, SWC and functions of software and environment system are inserted in the
Actions
folders of the tasks.
Processes/RE can be assigned as well that were furnished by the hardware configuration, e.g. for the hardware initialization or signal processing. Each process/
RE can be assigned exactly to one task.
-
Task_1
-
Actions
Mod1:Proc_1
Mod2:Proc_2
Mod1:Proc_3
+
Event
Fig. 4-36 OSC: Task with assigned processes
Tip
The RTA-OSEK and RTA-OSEK for PC operating systems do not support processes. Instead, INTECRIO automatically generates code for the tasks that invokes the assigned processes/RE as C functions.
The sequence in which the processes/RE are displayed corresponds to the processing sequence; the top process/RE is processed first, the bottom one last. The processes/RE can be moved within a task to change the processing sequence.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
In a similar way, exactly one event can be assigned to the
Event
folder of a task
(exception: RTA-OSEK for PC/PC). Events are driven by interrupts and serve for triggering actions. The
Event
folder contains the event that, upon occurrence, triggers the one-time execution of the respective task. Events can be hardwaredriven (e.g. watchdog alarm) or non-periodic (e.g. upon receipt of a trigger signal).
Tip
Only interrupt-triggered signals can be assigned to the
Event
folder. Only one event can be assigned to each task.
The configurations described can be performed manually or automatically via the automapping function.
Setting Up Interrupt Service Routines (RTA-OSEK/ES900 and RTA-
OSEK/RTPRO-PC without SWC only)
Interrupt service routines are set up in a similar way as tasks. A hardware interrupt is inserted in the
Interrupt
folder of an ISR; each HW interrupt can be assigned to exactly one ISR. The processes belonging to the ISR are inserted to the
Actions
folder. As for tasks, the process sequence in the
Actions
folder corresponds to the processing sequence.
Some HW interrupts have the AnalyzeCapable property (this property is set automatically by Hardware Configurator). In this case, the triggering event, i.e. the interrupt, can have sub-events that are analyzed at runtime. Each sub-event has a set of processes which are executed if required.
If such a HW interrupt is assigned to an ISR, the
Event Dependencies
subfolder is created automatically in the
Actions
folder. The
Event Dependencies
folder contains the sub-events; these are displayed as further sub-folders that contain the respective processes.
INTECRIO V4.6 - User’s Guide 105
106
The INTECRIO Components ETAS
Semantics is as follows: If the ISR is executed at runtime, and the analysis recognizes one or more events from the
Event Dependencies
folder, the process lists for those events are executed.
ISRs
ISR
Actions
Process 1
. . .
Event Dependencies
Event 1
Process a
. . .
. . .
Interrupt
. . .
HW Interrupt
Fig. 4-37 OSC: ISR
Two procedures exist for ISR configuration. The automapping function for ISRs uses the default procedure.
1. Default
This procedure should always be used, unless urgent scheduling requirements must be met.
A HW interrupt is assigned to a newly created ISR. Within the high-priority
ISR, only the analysis is executed. If required, the analysis task activates further tasks. These software tasks (with lower priority than the ISR) contain the processes to be executed (signal groups and user-defined processes).
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
2. Fastest response time
This procedure should only be used if signals must be evaluated as fast as possible.
After the ISR was created and the HW interrupt assigned, the event belonging to the signal is assigned to the
Event Dependencies folder.
The signal group, as well as the user-defined processes, are inserted in the
Event <event name>
subfolder.
The disadvantage is that the user-defined processes are executed with the high priority of the ISR and thus block most other actions in the system.
4.10 The Project Integrator
INTECRIO integration platform
Module interface
Interface for integrating software components
OS Configurator
Configuration of
OSEK operating system
Proj. Configurator
Network list of functions and modules
HC
Documentor
Project Integrator
Fundamental build process for the project integration
C code SCOOP-
IX file
ASAM-
2MC file
OIL file
Funct.
Network list
Hardwareconfig.
INTECRIO
Integration platform
Project integrator executable file
ASAM-
2MC file
Fig. 4-38 The project integrator
The project integrator (PI) combines all the components of the system – modules and functions, hardware interfacing, OS configuration, etc. – into an executable file. It essentially consists of a tool chain. The frame of this chain, i.e. the components, that provides the Make functionality is the PI build system.
Additional components are the PI plugin, which provides the variables parts of the build configuration, compiler, linker, etc.
Besides the executable file, an ASAM-MCD-2MC file is created for the experiment's project in which the ASAM-MCD-2MC files of the individual modules and additional information about the total project are combined. Optionally, the project integrator also creates a configuration file for RTA-TRACE.
INTECRIO V4.6 - User’s Guide 107
108
The INTECRIO Components ETAS
In contrast to the configurators, the project integrator does not have its own editors. In the graphical framework, it only reveals itself by using the Integration menu.
4.10.1 The Build Process
For a successful build process, all necessary files (
*.six
,
*.c
,
*.h
,
*.a2l
, ...) must be available for all modules. An installation of the BMT that generated these files is not necessary.
Overview
Fig. 4-39 schematically displays the phases of the build process and the file types
concerned. Each one of the phases, in turn, can be subdivided into individual steps.
External files
BMTs, config.
Parser
*.six
*.c
,
*.h
,
*.a2l
,
*.six
, ...
*.six
,
*.oil
,
*.xml
Code generation
External files
*.oil
,
...
Generated files
*.c
,
*.h
, ...
External files
Compiling
*.c
,
*.h
, ...
Compiler results
*.o
Linker
Linker result
*.l
Post processing
External files
*.o
,
*.lib
,
*.loc
External files
*.a2l
ASAM-2MC file
*.a2l
Fig. 4-39 The build process
Executable file
*.a2l.cod
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
At the start of the build process, the parser analyzes the configurations of all components and the total project, as well as the interface descriptions provided by the behavioral modeling tools (
*.six
).
For the code generation , the interface descriptions (
*.six
) and the configurations (
*.oil
, ...) created with different INTECRIO components are transferred to
C code. This code contains the information required in addition to the functional code of the modules.
For the compiling , object files are created from the files created during the code generation and the C code of the behavioral modeling tools. External C code files or header files can be added here. Only one compiler can be used for a system project.
The compiling results are linked into a binary file by the linker . External object files or libraries can be added here. Only one linker can be used for a system project.
In post-processing , the final executable file and the ASAM-MCD-2MC description file for the complete project is created from the binary file. The ASAM-MCD-
2MC files generated by the behavioral modeling tools are included here.
Sequence
Before the build process can run, it must be ensured that the system project contains the following components:
• A configuration of the hardware (see section 4.3),
• A configuration of the software (see section 4.8),
• A completely configured system project (see section 4.8, subsection "System Projects"), and
• An OS configuration (see section 4.9).
Once it is started, the build process runs automatically. Information about the current status and warnings or error messages are displayed. If a warning occurs, the process is continued; in case of a normal error, the current phase is completed before the process is cancelled. In case of a severe error or a missing source file, the build process is cancelled immediately, if necessary in the middle of a phase.
Code is created that can be executed in RAM with the option for a dynamic reconfiguration at runtime, and optionally code that can be executed in FLASH
(ES1000, ES900) or persistent memory (RTPRO-PC). This FLASH code does not offer dynamic reconfiguration). The latter can be executed in standalone mode on the rapid prototyping hardware. It is also possible to run only the code generation phase.
The files created in the build process are written to a directory that was specifically created for this system project,
<workspace>\cgen\system<n>
. This directory contains subdirectories for compiled files and other, temporary files.
The final executable file and the ASAM-MCD-2MC description are written to the
Results
subdirectory of the project directory (
...\<workspace>
), if nothing else is specified. The basic name for the executable file (
< b a s i c name>.a2l.cod
) and the ASAM-MCD-2MC file (
<basic name>.a2l
) can be predefined; the name of the system project is used by default.
INTECRIO V4.6 - User’s Guide 109
The INTECRIO Components ETAS
If nothing else is specified, the build process is incremental, i.e. only modified input files are included and only missing output files or output files created with other input files than the current ones are generated. Upon request, it is possible to delete all INTECRIO system files, except for the generated code from the behavioral modeling tools and the SCOOP-IX files, prior to the start of the build process. This forces a complete rebuild of the entire project. This cleanup can also be performed without subsequent build process.
4.10.2 ASAM-MCD-2MC Generation
The build process of the project integrator generates an ASAM-MCD-2MC description (
*.a2l
file) of the project that meets the specifications of the working group for standardization of automation and measuring systems, version
1.5
1 . Such a description is required for the ETAS Experiment Environment to identify the model elements that must be measured or calibrated.
During the creation of this ASAM-MCD-2MC file, the
*.a2l
files provided by the behavioral modeling tools for the modules contained in the project are combined. Furthermore, additional entries are added that describe the project as a whole.
In general, an ASAM-MCD-2MC file contains the following components:
• Project information
• Descriptions of data structures used in the project
• Descriptions of variables and parameters
• Descriptions of external interfaces
• Descriptions of communication protocols
• Descriptions of conversion formulas
110
1. The current specification can be obtained here: http://www.asam.de/
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
4.11 The ETAS Experiment Environment
M
ATLAB
®
/Simulink
®
ASCET User Code
M
INTECRIO
M ATLAB connectivity
ASCET connectivity
INTECRIO
Integration plattform
RTA-TRACE
ETAS Experiment Environment
RTA-TRACE connectivity
VP-PC
E.g. ETK
E-Target
EE/INTECRIO components
Other programs
DVE Driver/vehicle/environment
Fig. 4-40 The ETAS Experiment Environment used with INTECRIO
This section provides an introduction to experiments in general and the ETAS
Experiment Environment in particular. Using the ETAS Experiment Environment is described in the online help.
Experimenting can generally be subdivided into three steps:
• Preparing the experiment
• Performing the experiment
• Analysis after the experiment
Preparing the experiment contains creating a prototype that is specifically suited for this special experiment, as well as the creation of a suitable environment for the experiment. The analysis following the experiment essentially contains the analysis of recorded data with suitable tools 1 . However, only the performance of experiments is dealt with at this point.
1. for example, the ETAS Measure Data Analyzer (MDA)
INTECRIO V4.6 - User’s Guide 111
112
The INTECRIO Components ETAS
Prototypes that use an ES1000 or VP-PC target contain one memory page, prototypes that use an ES910 or RTPRO-PC target contain two memory pages. To make use of both memory pages, you have to use INCA/INCA-EIP as experiment environment; the ETAS Experiment Environment does not support multiple memory pages. See the INCA and INCA-EIP documentation for details on using memory pages.
4.11.1 Validation and Verification
If the software components or the complete application software must be vali-
dated and verified in the function development phase (see also section 2.4
"INTECRIO in the Development Process"), it generally requires an experiment
environment. It must provide all the functions required for the validation and verification.
In general, an experiment environment must deal with the following tasks:
• Loading code and data onto the target
• Starting, stopping and interrupting the experiment
• Measuring and calibrating different elements, e.g.
– Values
– Configurations with different means:
– GUI elements (e.g. oscilloscopes)
– Back animation of the graphical software model
• Use of stimuli, if necessary
The tasks vary with the targets used.
It is also necessary that all the settings required for the validation and verification during the creation of the prototype are performed so that it is possible to perform a useful experiment.
4.11.2 Measuring and Calibrating
In general it can be said that the main task of an experiment environment consists of two items: measuring and calibrating. Measuring means that the current status of an element is read and made visible in an environment-dependent form. Calibrating means that the current status of an element is changed or
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components adjusted in a suitable way. For this reason, an experiment environment is characterized by two different capabilities: measurement and visualization of element statuses as well as calibration (adjustment) of element statuses.
ETAS
Experiment Environment
Measuring
INTECRIO
Module variables
INTECRIO
Function network list - Measurement
INTECRIO
OS real-time behavior
INTECRIO
I/O driver - Values
Calibrating
INTECRIO
Module parameters
INTECRIO
Function network list - Changes
INTECRIO
OS-config. - Modifications
INTECRIO
I/O driver - Values
Fig. 4-41 Main tasks of the ETAS Experiment Environment
The following elements can be measured in the ETAS Experiment Environment:
• Module variables – Variables within the modules specified with BMTs
• Function network list – The values of the connections between the different software and hardware modules can be measured to obtain information about the current signal value exchange between the components.
• Real-time behavior of the operating system – The current status of the operating system, i.e. the current task, execution times, etc., can be displayed.
• I/O driver – The values provided or consumed by a driver are of interest just like the current driver configuration.
The following elements can be calibrated in the ETAS Experiment Environment:
• Module parameters – The parameters in the various modules can be calibrated.
• Function network list – The connections between software and hardware modules can be changed at runtime. This is an essential capability for validation and verification.
Calibrated parameters can be saved and loaded.
INTECRIO V4.6 - User’s Guide 113
114
The INTECRIO Components ETAS
4.11.3 Experimenting with Different Targets
In order for experiments to run on a target, the target must support different interfaces. These properties depend on the requested functionality, as discussed
in section 4.11.1 "Validation and Verification". Therefore, the target must be
prepared to allow for the combination of the different tasks of the experiment environment as well as the measuring and calibrating of the relevant elements.
Module A Meas./calib.
interface
Module B Module C
INTECRIO-RTE (crossbar)
Communication driver
Configuration interface for communication
OSEK operating system
OS configuration interface
I/O driver
(hardware abstraction layer)
....
I/O interface Experiment interface
Fig. 4-42 Experiment interfaces
Fig. 4-42 shows the different experiment interfaces that are required so that all
the measuring and calibrating tasks displayed in Fig. 4-41 can be performed.
• The measuring and calibrating interface – for access to variables and parameters,
• INTECRIO-RTE (Crossbar) – for access to the function network list,
• The configuration interface for communication – for access to the I/O driver values,
• The I/O configuration interface – for access to the configuration of the I/O drivers,
• The OS configuration interface – for access to the OS configuration.
However, not every target has to feature all of these interfaces; it is sufficient if the interfaces required for the respective task are available.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
Real-time targets for rapid prototyping should support all listed interfaces since this type of experiment requires the possibility for quick changes for verification and validation.
Module B
Module A Meas./cal. interface
Module C
INTECRIO-RTE (crossbar)
Communication driver
Configuration interface for communication
OSEK operating system
OS configuration interface
I/O driver
....
ETAS
Experiment Environment
Measuring
INTECRIO
Module variables
Calibrating
INTECRIO
Module parameters
INTECRIO
Function network list - Measurement
INTECRIO
Function network list - Changes
INTECRIO
OS real-time behavior
INTECRIO
I/O driver - Values
INTECRIO
OS config. -
Modifications
INTECRIO
I/O driver - Config.
RTPRO-PC
Fig. 4-43 Experiment interfaces for rapid prototyping targets
Fig. 4-43 shows which interface takes on what measuring and calibrating tasks
for a rapid prototyping system.
However, for experiments on the production electronic control unit there is no possibility to calibrate the configurations during the running experiment or – except for the real-time behavior of the operating system – to measure. For this reason, only the measuring and calibrating interface as well as the OS configura-
tion interface are required, the others can be omitted (see Fig. 4-44).
Module B
Module A Meas./calib. interface
Module C
Runtime Environment
Communication driver
OSEK operating system
OS configuration interface
I/O driver
....
ETAS
Experiment environment
Measuring Calibrating
Module variables Module parameters
Function network list - Measurement
OS real-time behavior
I/O driver - Values
Function network list - Changes
OS-config. -
Modifications
I/O driver - Config.
Fig. 4-44 Experiment interfaces for production electronic control units
INTECRIO V4.6 - User’s Guide 115
116
The INTECRIO Components ETAS
4.11.4 Rapid Prototyping Experiment with the ETAS Experiment Environment
In principle, there are two types of experiments with rapid prototyping systems: bypass and fullpass experiment. The performance of an experiment is roughly the same in both cases; the user wants to execute the prototype, measure values and calibrate parameters. Nevertheless, there are clear differences which are described in the following sections.
Bypass Experiment
A bypass experiment exists if only parts of the application software are computed on the rapid prototyping hardware (ES1000, ES900 or RTPRO-PC).
Bypass experiments are preferably used if only a few software functions must be developed and an electronic control unit with validated software functions – perhaps from a predecessor project – is already available. This electronic control unit then needs to be modified so that it supports a bypass interface. The necessary software modifications with respect to the electronic control unit are referred to as bypass hooks . The effort for creating a bypass experiment is low.
ES113x/ES910/RTPRO-PC
Module A
RT
PR
O-
PC
Module B Module C
INTECRIO-RTE (crossbar) ECU with bypass link
Communication driver
OSEK operating system
I/O driver
(hardware abstraction layer)
....
Fig. 4-45 Bypass experiment: Scheme
A bypass system can be considered as a system with two processors: The electronic control unit with bypass link is one processor, the other processor is the rapid prototyping system. The application software (sometimes even a part of the platform software) is distributed to these two processors which are linked with each other by means of a bypass synchronization mechanism (e.g. ETK or
CAN bus).
The calculation of the bypass function is generally initiated by the electronic control unit via a control flow interface or trigger; the output values of the bypass function are monitored in the electronic control unit for plausibility. In this case, electronic control unit and rapid prototyping system operate synchronously.
Alternatively, it is also possible to implement an unsynchronized communication without trigger.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
Since the two processors are forming a system, it is necessary that the controlling
PC views them as one system. This means that access to both processors is assigned by a control application. This is easy to implement by using INCA since
INCA allows access to the rapid prototyping target as well as the electronic control unit target.
INTECRIO and the ETAS Experiment Environment support bypass experiments, too. During a bypass experiment with INTECRIO, you can access the experimental target from the ETAS Experiment Environment, i.e. you can measure and calibrate the bypass hook variables. However, you have no direct access to the ECU.
INTECRIO + ETAS Experiment Environment
Sensors Intelligent I/O
E-Target
Fig. 4-46 Bypass experiments with INTECRIO + ETAS Experiment Environment
Fullpass Experiment
If an electronic control unit with validated software functions and bypass interface is not available or if additional sensors and actuators must be validated, fullpass experiments are frequently preferred. The real-time behavior must be guaranteed by the rapid prototyping hardware and possibly monitored; all sensor and actuator interfaces required by the function must be supported.
The environment of INTECRIO refers to a fullpass experiment if the entire application software (the control algorithm) runs on the rapid prototyping hardware
(ES1000, ES900 or RTPRO-PC). The hardware runs in standalone mode (without
INTECRIO V4.6 - User’s Guide 117
The INTECRIO Components ETAS electronic control unit); the I/O interfaces form the connection to the outside
world (see Fig. 4-47); sensors and actuators are directly connected to the hard-
ware.
ES113x/ES910/RTPRO-PC
Module A
Module B
ES1130/ES1135/ES910
INTECRIO-RTE (crossbar)
RT
PRO
-PC
Communication driver
OSEK operating system
I/O driver
(hardware abstraction layer)
....
Fig. 4-47 Fullpass experiment in standalone mode
ES1000/ES900
I/O interfaces
INTECRIO + ETAS
Experiment Environment
Sensors
RTPRO-PC
Intelligent I/O
E-Target
118
Fig. 4-48 Fullpass experiment with INTECRIO + ETAS Experiment Environment
The other option consists of using INCA/INCA-EIP instead of the ETAS Experiment Environment.
INTECRIO V4.6 - User’s Guide
ETAS The INTECRIO Components
X-Pass Experiment
The X-pass experiment is a mixture of bypass and fullpass experiment. The rapid prototyping hardware (ES1000, ES900 or RTPRO-PC) utilizes the electronic con-
trol unit with bypass hooks as interface to the outside world (see Fig. 4-49).
ES113x/ES910/RTPRO-PC
Module A
RT
PR
O-
PC
INTECRIO-RTE (Crossbar)
ECU with bypass link
Communication driver
OSEK operating system
I/O driver
(hardware abstraction layer)
....
Fig. 4-49 X-pass experiment with electronic control unit as I/O
4.11.5 Virtual Prototyping Experiments with the ETAS Experiment Environment
The ETAS Experiment Environment offers the same options for virtual prototyping as it does for rapid prototyping, e.g. to view variables and to change parameters. In parallel, this is possible directly in M ATLAB /Simulink or in ASCET, as well.
In addition, users can change parameters and module connections on the running prototype in order to compare various model configurations.
4.12 The Documentor
The INTECRIO documentor offers the possibility to generate documentation for the components of a system project. The documentation can be generated in
HTML or PDF format, and the be printed or used in other documents.
Besides general information on the system project, the documentation file contains information on the software and hardware systems and the OS configuration. The exact content can be configured; the following specifications are possible:
System Project
• general information (INTECRIO version, creation date, etc.)
• workspace information
• system-level connections (i.e. between hardware and software)
INTECRIO V4.6 - User’s Guide 119
120
The INTECRIO Components ETAS
Software System
• information on the software system (general information, signal sources/ sinks of software system and functions, connections on software system level, etc.)
• information on the contained modules (general information, information regarding module code and files, signal sources/sinks of modules, parameter, processes, etc.)
Environment System
• information on the environment system (general information, signal sources/sinks of environment system and functions, connections on environment system level, etc.)
• information on the contained modules (general information, information regarding module code and files, signal sources/sinks of modules, parameter, processes, etc.)
Hardware System
• information on the hardware system (general information, ECU, CPU, signal sources/sinks of hardware, connections on hardware system level, etc.)
• information on boards (ES1000, RTPRO-PC) and devices (name, signal groups, signals, etc.)
OS Configuration
• general information
• information on application modes and tasks
• information on OS actions (i.e. processes)
• information on events
Details regarding the setup and generation of documentation can be found in the online help.
4.13 RTA-TRACE Connectivity
RTA-TRACE connectivity is an add-on to the ETAS Experiment Environment. It allows for connecting RTA-TRACE with the rapid prototyping hardware or the PC in case of virtual prototyping. By using RTA-TRACE, the time behavior (VP) or the real-time behavior (RP) of the experiment on the target (ES113x, ES910,
RTPRO-PC or VP-PC) can be displayed.
Additional information about RTA-TRACE and how to operate this tool can be found in the RTA-TRACE documentation.
INTECRIO V4.6 - User’s Guide
ETAS SCOOP and SCOOP-IX
5 SCOOP and SCOOP-IX
This chapter contains a concept for the description, management and exchange of C code interfaces. The description and exchange of code interfaces is a very important topic in the context of INTECRIO since the interfaces for integration are of significant importance.
In the framework of the embedded control software, the smooth integration of simple C code is affected by the fact that certain semantic pieces of information are not part of the standard C code:
• Implementation data, such as conversion formula, minimum, maximum and limitation for C variables as well as return values and arguments of
C functions,
• Grouping information for characteristic values (lookup tables) represented by several C arrays with disjointed definitions or embedded in C structures
( struct
),
• Information about use that indicate whether an element is intended for measurements or calibration with running experiment, and
• Origin of the model and specific data (e.g. model name, physical unit, embedded component or block, notes, use as message, process, signal or parameter), particularly for automatically generated source files.
Furthermore, additional information is more or less obviously "hidden" in the
C code and cannot easily be extracted:
• Memory classes that are written to by non-standard target-specific
#pragma
instructions, and
• Attributes of C variables or C functions that are written to by non-standard target-specific modifiers such as inline
or far
.
The concept introduced in this chapter that is used to collect all the necessary interface information and make it available, is referred to as SCOOP ( Source
Code, Objects, and Physics ).
The approach of SCOOP essentially consists of an interface description language
(roughly comparable with known interface description languages such as that of
CORBA 1 and COM from Microsoft) and tools for creating, managing and using the interface descriptions.
The interface description language SCOOP-IX
(see also section 5.2 "The SCOOP-
IX Language" on page 122) is intended for the detailed collection of all the infor-
mation about interfaces in a wider sense. SCOOP-IX descriptions can be used for the data exchange between tools or supplied together with open or compiled
C code for later integration.
5.1
The SCOOP Concept
The approach of SCOOP aims at providing a uniform description of the aforementioned information, together with the actual interfaces of the code on
C level. Besides the initially mentioned semantic information, a SCOOP-IX interface description essentially consists of the following information:
1. Common Object Request Broker Architecture, developed by the Object Management Group (OMG, see http://www.omg.org/ )
INTECRIO V4.6 - User’s Guide 121
122
SCOOP and SCOOP-IX ETAS
• Name, type and magnitude of C variables
• Name, return value and signature of C functions
• File origin of C elements
The combination of this information to an interface description language offers a very powerful tool for the following applications:
• Representation of interface inside of INTECRIO and its components, particularly the following:
– Experimental target configurator
– OS configurator
– Project configurator
– Project integrator
• Representation of interfaces for communication between different tools and the interfacing of ASCET and M ATLAB /Simulink to INTECRIO.
SCOOP provides a formal interface description that is suitable for the following purposes:
• Distribution of object files or libraries together with a comprehensive interface description on the levels of C code, physics and semantics with the support of know-how protection (IP protection).
• Check for compatibility of interfaces of different software modules, not only on the level of C code (name, type, signature), but also on the physical (implementation, unit) and semantic (record layout, use as message or process) level.
• Generation of connection code or wrapper functionality to adjust nonconforming module interfaces to each other for integration.
• To provide tools (such as the OS configurator) with the opportunity of using information further that is transferred by code generators (e.g. all
C elements that represent ASCET processes and messages).
5.2
The SCOOP-IX Language
SCOOP-IX is short for SCOOP Interface Exchange Language ; this language is the basis of the SCOOP concept. As mentioned earlier, SCOOP-IX provides means for describing the interfaces of C modules to enable their integration with INTEC-
RIO.
The SCOOP-IX language is based on XML and, therefore, well suited for use in
INTECRIO, ASCET or similar tools.
5.2.1
Modules and Interfaces
SCOOP views a module either as an individual compiling unit (usually a C file) or as a combination of several compiling units (a group of C code or object files, libraries, etc.) with a common interface. Exactly one SCOOP-IX file belongs to a module.
Global C variables as well as C functions can be part of a module interface. If this is the case, they are referred to as interface elements below.
INTECRIO V4.6 - User’s Guide
ETAS SCOOP and SCOOP-IX
Interface elements are characterized as partners in an access or call relationship beyond module boundaries. For this reason, a C declaration or definition is considered to be the correspondence of an interface element of the module in the following cases:
• Export interface : A C variable or C function is globally defined in the module and available for external linking (not declared as static
). The exact definition of the element can be determined directly. Elements that cannot be accessed from outside the module should be omitted from the
SCOOP-IX description.
• Import interface : A C variable is accessed from within the module (read, write or address operation) or a C function is called within the module
(directly or via address operation), but the element is defined outside of the module. The exact definition of the element can be determined by examining the associated declaration (whose existence is guaranteed with
MISRA
1
compatibility).
5.2.2
Description of the C Code Interface
The description of the C code interface consists of information that is contained in the source code. The elements of the code interfaces fall into two categories, variables and functions, and they each contain specific descriptions of the interface elements.
Additional general information about the elements and the modules are also addressed by SCOOP-IX and are described below.
The interface description of a C variable (
<dataElement>
133, and 134) essentially consists of the following information:
• The name of the variable (
<dataCInterface>
among others)
• The C type of the variable (
<type>
block, see page 133, among others)
• The number of entries in x (and y) direction if the variable is an array
(matrix)
• Information for storage in memory (such as extern
, static
, const and volatile
, far
or huge
,
#pragma
instructions)
• An optional initialization value (
<initValue>
among others)
Accordingly, the interface description of a C function (
<functionElement>
block, see page 136) essentially consists of the following information:
• Name of the function (
<functionCInterface>
• Information for storing the function in memory (such as extern
and static
(general), inline
(target-specific),
#pragma
instructions)
• Arguments and return values of the function, such as:
– Names of all arguments
– C types of all arguments and the return value (
<return>
block, see
– Information for storage in memory (such as const
, far
or huge
)
1. Motor Industry Software Reliability Association
INTECRIO V4.6 - User’s Guide 123
124
SCOOP and SCOOP-IX ETAS
– Sequence in which the arguments appear
In addition to the specific information described so far about C variables and
C functions, general information about each element are important, such as the following:
• Type of interface element (import vs. export; interfaceKind
parame-
ter, see page 133 and page 136),
• File origin (
<fileOrigin>
block, see page 133 and page 136)
Each module interface is described not only by its elements, but also by the following general information :
• File origin of elements (
<fileContainer>
• C header files to be integrated (also
<fileContainer>
block).
• Status of the module (source code, object file or library;
<constitution>
block and mode
• Hardware target (
<target>
block, see page 130) and compiler (
<tool>
block, see page 130) that the module requires.
• Compiler options and similar settings that were used for the creation or must be used for further processing (
<configuration>
block, see
5.2.3
Description of Semantic Information
In contrast to the information about the C code interface, semantic information cannot be extracted from source code through analysis. Instead, this type of interface information must be created manually or automatically by a code generator together with the actual code generation. ASCET and M ATLAB /Simulink connectivity offer the latter option.
Semantic information about elements is divided into the categories "Model Ori-
gin", "Implementation" and "Use". These categories are explained in the fol-
lowing sections. Additional module-specific information is also considered (see
Model Origin
If the C source code described was automatically generated or manually created from a more or less formal model (such as block diagram, state machine, control or data flow diagram), the origin of each interface element can be described in the model.
The model origin is used primarily for documentation purposes and for improved orientation of the user. Configuration tools, such as the project configurator, can display this information, thereby providing the user a means for identifying model elements.
In addition, the information about the model origin can be used to forward specific information to other tools. For example, if ASCET marks the C elements that were generated for processes and messages, it allows the OS configurator to locate precisely these elements out of the entire interface description and to present to the user as possible candidates for the configuration of the operating system.
INTECRIO V4.6 - User’s Guide
ETAS SCOOP and SCOOP-IX
In addition to that, the description of the origin allows for enabling semantic checks in the model at the highest level with respect to consistency or plausibility across domain and tool boundaries.
Information about the model origin are divided into general and model-specific information. The latter are explained using examples of ASCET and M ATLAB /
Simulink.
General information about the model origin (
<modelOrigin>
block, see
page 133 and page 136) can consist of the following elements:
• A model name such as the displayed name of the interface element
(
<name>
block, see page 133 and page 136) or the element name of a
memory element, signal, method, etc.
• A unique identifier in the model ( identifier
• A model path within a hierarchical model structure (
<modelLink>
block,
• Model type such as continuous
, discrete
,
Boolean
, array
, etc. for C variables, return values and arguments of functions (
<modelType>
• Model form such as variable, parameter or constant for C variables
(
<modelKind>
block, kind
option, see page 134 and page 136)
• Visibility in other models, either public
or private
( visibility
option, see page 134 and page 136)
public
visibility corresponds to the ASCET scope exported , private
visibility corresponds to the ASCET scope local .
• Logical flow direction for C variables, such as input port or output port
(
<flowDirection>
• Physical unit for C variables, return values and arguments of functions
• Value range on the model level for C variables, return values and arguments of functions
• Textual notes, such as user comments, additional non-specific model information, etc. (
<annotation>
block, see page 134 and page 137)
Depending on the BMT used, certain domain-specific information is important for the integration of SCOOP-IX modules.
The following information is of special interest for code that was generated with
ASCET:
• The ASCET component in which the equivalent of the respective interface element is embedded
• The type of component (class, module or project;
<pathNode>
block with kind="asd:module"
• The type of equivalent of the interface element (element, message, resource, method, process, task;
<pathNode>
block with kind="asd:element"
In real-time operating systems, such as ERCOS EK , processes on C code level are represented by means of void/void
functions. With respect to the OS configuration and project integration, the following information is of interest, among others:
INTECRIO V4.6 - User’s Guide 125
126
SCOOP and SCOOP-IX ETAS
• Messages that are accessed within the process or any C function that is called inside of them (
<messageAccess>
as the respective access mode (send, receive; send
• Resources that are accessed within the process or any C function that is called inside of them (
<resourceAccess>
• Time requirements on the model level (
<constraint>
block, see
– Period (
<period>
block, see page 136), offset, deadline and priority
( priority
option, see page 136) of the execution,
– Type of trigger (initialization, timer, interrupt or software; trigger
– Scheduling mode (preemptive, cooperative or non-preemptable;
<scheduling>
Since the actual priority levels are dependent upon the operating system and the CPU, imprecise priorities such as background
, low
, normal
, high
and scheduler
are allowed.
The following information is of special interest for code that was generated with
M ATLAB /Simulink:
• M ATLAB /Simulink subsystem or block that contains the counterpart to the respective interface element, as well as the type of subsystem or block.
• Type of counterpart to the interface element (signal or parameter).
The scan rates of a M ATLAB /Simulink model can be formulated by means of comparable time restrictions such as the aforementioned ones.
Implementation
To allow for data consistency checks and the generation of connection code, information about the implementations of the C code interfaces is required. This applies to C variables, return values and arguments of functions.
Implementation information (
<implementation>
comprised of
• A conversion formula that describes the relationship between the data of a model element and those of its C code equivalent (
<conversion>
<conversionRef>
• Minimum and maximum values on the C code level (
<valueRange>
• The use of ASCET limiters and (in SCOOP-IX V1.2) resolution scheme if the boundaries of the value range are exceeded (
<saturation>
block, see
The
<saturation>
block contains the options value
, resolution and assignment
. Depending on the settings in the ASCET implementation editor, the options are set as follows.
– value
is set to true
( false
) if Limit to maximum bit length is activated (deactivated)
– resolution
is set to automatic
, keep
, or reduce
, depending on the selection in the combo box next to Limit to maximum bit length .
INTECRIO V4.6 - User’s Guide
ETAS SCOOP and SCOOP-IX
– assignment
is set to true
( false
) if Limit Assignments is activated
(deactivated).
For Simulink models, or for ASCET variables that use no limiter, the
<saturation>
block is omitted.
• For SCOOP-IS files generated with ASCET V6.4: The
<zeroExcluded>
block (see page 134) always contains
value="false"
.
For SCOOP-IX files generated with ASCET V5.0 - V6.3: The
<zeroExcluded>
block contains information whether zero is explicitly excluded from the interval.
Use
The following semantic information about the use of interface elements is important (only data elements):
• The relationship between characteristic values and the respective
C variables from which they are formed, as well as information about the characteristic value, such as axes, dimensions and record layout
• Use for measurement or calibration:
<usage>
surement) or page 135 (calibration)
• Pseudo addresses for the simulation interface to the experimental target or ECU addresses with the corresponding bit masks
Module Data
The following add-on information may be contained in the SCOOP-IX description of a module (
<moduleInfo>
• Module name (
<name>
• The module version concerning the contents of the interface description
(
<version>
• Date and time of the creation (
<dateTime>
block with the kind="created"
• Date and time of the last modification (
<dateTime>
block with the kind="lastModified"
• Degree of completion of the interface description (
<completion>
block, see page 129), i.e. one of the following statuses:
– basic
(only pure C code interface data, no semantic information)
– in progress
(intermediate format, semantic information partially completed)
– full
(document is considered to be stable, semantic information not compulsorily complete)
• Information about user and company (blocks
<company>
,
<user>
and
<creators>
• Name and version of the generating BMT (
<tool>
• Textual notes (
<annotation>
INTECRIO V4.6 - User’s Guide 127
128
SCOOP and SCOOP-IX ETAS
5.3
Creation of SCOOP-IX and Example
Tools that are either a part of INTECRIO or are coupled to INTECRIO create
SCOOP-IX descriptions if C code is created for the integration. In the case of
ASCET and M ATLAB /Simulink, the SCOOP-IX generation is performed by the respective connectivity tool.
An example for a simple SCOOP-IX file created with ASCET can be found below.
The example is used exclusively for representing an interface description in
SCOOP-IX, it does not claim to be meaningful or correct.
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE module [
<!ENTITY szlig "ß">
<!ENTITY copy "©">
<!ENTITY baseTypes-asd SYSTEM
'c:\ETAS\ASCET6.4\Formats\SCOOP-IX\1.2\common\ baseTypes-asd.xml'>
]>
↵
↵
<?xml-stylesheet type="text/xsl" href="c:\ETAS\
ASCET6.4\Formats\SCOOP-IX\1.2\common\ showSCOOP-IX.xsl"?>
<!--
<h1>SCOOP-IX</h1>
↵
↵
<p>
<strong>Copyright © 2002-2004 ETAS GmbH</strong>,
↵
Borsigstraße 14, D-70469 Stuttgart.
↵
<em>All rights reserved.</em>
</p>
-->
< module xmlns="http://www.etas.de/scoop-ix/1.2" xmlns:ix="http://www.etas.de/scoop-ix/1.2" xmlns:asd="http://www.etas.de/scoop-ix/1.2/ modelDomain/ascet"
↵ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.etas.de/scoop-ix/1.2
↵ c:\ETAS\ASCET6.4\Formats\SCOOP-IX\1.2\Schemas\
↵ scoop-ix-domain-asd.xsd" xmlns:html="http://www.w3.org/1999/xhtml" >
< directoryLocations scheme="ASCET 6.4">
< directory identifier="integratorDir" path="E:\ETAS\INTECRIO4.6\" >< /directory >
↵
< directory identifier="toolDir" path="c:\ETAS\ASCET6.4\" >< /directory >
↵
< directory identifier="modelDir"
↵ path="c:\ETASData\ASCET6.4\Database\INTECRIO \" >
↵
< /directory >
INTECRIO V4.6 - User’s Guide
ETAS SCOOP and SCOOP-IX
< directory identifier="codeDir" path="c:\ETASData\ASCET6.4\Database\INTECRIO\
Project\CGen\" >< /directory >
< /directoryLocations >
↵
↵
< moduleInfo identifier=
"_040VSM3H60001KO7102G5GFA1O5G0">
< name >ASDSimpleModel< /name >
< modelLink href="asd://{{modelDir}}?Training/
ASDSimpleModel" >< /modelLink >
< version major="1" minor="0" ></version>
< dateTime kind="created" year="2011" month="02" day="13" hour="15" minute="37" second="04" >
< /dateTime >
< dateTime kind="lastModified" year="2011" month="03" day="04" hour="17" minute="14" second="44" > </ dateTime >
< completion degree="full" >< /completion >
↵
↵
↵
↵
↵
↵
< suitability >
< application domain="rapidPrototyping" addressesAvailable="true" instanceTreeRootIdentifier=
"_040VSM3H60001KO7102G5GFA1O5G0instance" setGetDeltaTIdentifier=
"__040VSM3H60001KO7102G5GFA1O5G0">
< /application >
< /suitability >
< company name="ETAS GmbH" department="ETAS/PAC-F1"
↵ city="Stuttgart" country="Germany" />
< user lastName="Doe" firstName="John" title="Dr" >
↵
< /user >
< creators >
< user lastName="Doe" firstName="John" title="Dr" >< /user >
↵
< tool kind="modeler" vendor="ETAS GmbH" name="ASCET">
↵
< version major="6" minor="1" revision="1" >
↵
< /version >
↵
↵
↵
↵
↵
↵
< configuration >
< option identifier="ignoreInternalMessages"
↵
> false< /option >
< /configuration >
< /tool >
< tool kind="codeGenerator" vendor="ETAS GmbH" name="ASCET">
↵
< version major="6" minor="1" revision="1" >
↵
< /version >
INTECRIO V4.6 - User’s Guide 129
130
SCOOP and SCOOP-IX ETAS
< mode name="experiment" value="Implementation" >< /mode >
< configuration >
< option identifier="Code Generator" >
Implementation Experiment< /option >
< option identifier="Target" >Prototyping
< /option >
...
1
↵
↵
↵
< /configuration >
< /tool >
< /creators >
< annotation >
< ix:documentation xmlns="http://www.w3.org/
1999/xhtml">
↵
< p >This is a sample module interface description file. It is used for demonstrating an interface description in the < b >SCOOP-IX< /b >
↵ language.< /p >
< p >Neither is its content supposed to make
↵ any sense at all, nor has its correctness
↵ been checked by compilation.< /p >
↵
↵
< /ix:documentation >
< /annotation >
< /moduleInfo >
< codeInfo >
< constitution mode ="sourceCode" >< /constitution >
< dateTime kind="created" year="2011" month="02" day="13" hour="15" minute="38" second="4" >
< /dateTime >
↵
↵
< target >
< processor vendor="Motorola" model="MPC750" >
< /processor >
↵
< board vendor="ETAS GmbH" model="Prototyping" >
↵
< /board >
< tool kind="compiler" vendor="GNU Project" family="GNU Compiler Collection" name="GNU C Compiler for Embedded PowerPC target">
↵
↵
↵
< configuration >
< optionKind name="macroDefine" prefix="-D" >
↵
< /optionKind >
1. A SCOOP-IX file contains all settings from the project properties. For documentation purposes, only the first two are listed.
INTECRIO V4.6 - User’s Guide
ETAS SCOOP and SCOOP-IX
< optionKind name="includeDirectory" prefix="-I" >< /optionKind >
<!-- ASCET specific defines -->
< option kind="macroDefine" name="EXT_INTEGRATION" >< /optionKind >
↵
↵
<!-- ASCET specific include directories -->
< option kind="includeDirectory">
<![CDATA[{{codeDir}}]]>< /option >
↵
< /configuration >
< /tool >
< /target >
< target >
< board vendor="ETAS GmbH" model="INTECRIO
Generic Experimental Target" >
< /board >
< tool kind="compiler" vendor="GNU Project" family="GNU Compiler Collection" name="GNU C Compiler" >
↵
↵
↵
< configuration >
< optionKind name="macroDefine" prefix="-D" >
↵
< /optionKind >
< optionKind name="includeDirectory"
↵ prefix="-I" >< /optionKind >
< option kind="macroDefine" name=
↵
"EXT_INTEGRATION" >< /option >
< option kind="includeDirectory" >
↵
<![CDATA[{{codeDir}}]]>< /option >
< /configuration >
< /tool >
< /target >
< /codeInfo >
< fileContainer complete="false">
< pathBase path="{{codeDir}}" ></pathBase>
<!-- model specific C files -->
< file name="_asd_pid.c" kind="body" >< /file >
< file name="asdsmpm.c" kind="body" >< /file >
< file name="conf.c" kind="body" >< /file >
< file name="modulem.c" kind="body" >< /file >
< file name="asdsmpm.h" kind="header" >< /file >
< file name="conf.h" kind="header" >< /file >
< file name="modulem.h" kind="header" >< /file >
<!-- additional files -->
INTECRIO V4.6 - User’s Guide 131
132
SCOOP and SCOOP-IX ETAS
< file name="ASDSimpleModel.a2l" content="dataDescription" format="ASAM-2MC" formatVersion="1.5" >< /file >
< /fileContainer >
< interface >
< modelLinkBase href="asd://
{{modelDir}}?Training/ASDSimpleModel/" >
< /modelLinkBase >
↵
↵
< pathBase path="{{codeDir}}" >< /pathBase >
< headerFile name="asdsmpm.h" >< /headerFile >
< headerFile name="conf.h" >< /headerFile >
< headerFile name="modulem.h" >< /headerFile >
< usage layoutFamily="asd:standardLayout" >< /usage >
&baseTypes-asd;
< definitions >
< conversion name="ident">
< rationalFunction >
< numerator bx="1" >< /numerator >
< denominator f="1" >< /denominator >
< /rationalFunction >
< /conversion >
< /definitions >
< dataElement interfaceKind="export">
< dataCInterface identifier=
"MODULE_IMPL_ClassObj.Out1->val">
↵
< type >< typeRef name="real64" >< /typeRef >< /type >
< fileOrigin name="MODULEM.c" >< /fileOrigin >
< initValue value="0.0" >< /initValue >
< /dataCInterface >
< modelOrigin identifier="ASDSimpleModel.
Module.Out1">
< name >Out1< /name >
< modelLink href="Module.Out1" >< /modelLink >
< modelLocation >
↵
< pathNode name="Module" kind="asd:module">
< pathParameter name="asd:implementation"
↵ value="Impl" >< /pathParameter >
< pathParameter name="asd:dataSet" value="Data" >< /pathParameter >
↵
< /pathNode >
< pathNode name="Out1" kind="asd:element" >
↵
< /pathNode >
INTECRIO V4.6 - User’s Guide
ETAS SCOOP and SCOOP-IX
< /modelLocation >
< modelKind kind="message" visibility="public">
< flowDirection in="false" out="true" >
< /flowDirection >
↵
< /modelKind >
< modelType type="continuous" >< /modelType >
< annotation >
< ix:documentation xmlns=
"http://www.w3.org/1999/xhtml" lang="en-US">
↵
↵
↵
This is output message < i >Out1< /i > of continuous type.
< /ix:documentation >
</ annotation >
< /modelOrigin >
< implementation >
< conversionRef name="ident" >< /conversionRef >
< valueRange min="-2147483648"
↵ max="2147483647" >< /valueRange >
< saturation value="true" resolution="reduce"
↵ assignment="true" >< /saturation >
< zeroExcluded value="false" >< /zeroExcluded >
< /implementation >
< usage measurement="true" virtual="false" variant="false" >
< address kind="pseudo" >
< BLOB kind="KP_BLOB" device="E_TARGET" >
<![CDATA[2 1001 1 1001 1]]>< /BLOB >
< /address >
< /usage >
< /dataElement >
↵
↵
< dataElement interfaceKind ="export">
< dataCInterface identifier=
"ASDSIMPLEMODEL_IMPL_ClassObj.Module-> myProduct->val">
↵
↵
< type >< typeRef name="sint32" >< /typeRef >< /type >
< fileOrigin name="MODULEM.c" >< /fileOrigin >
< initValue value="0" ></initValue>
< /dataCInterface >
< modelOrigin identifier =
"ASDSimpleModel.Module.myProduct">
< name >myProduct< /name >
< modelLink href="ASDSimpleModel.Module.
myProduct" >< /modelLink >
< modelLocation >
↵
INTECRIO V4.6 - User’s Guide 133
134
SCOOP and SCOOP-IX ETAS
< pathNode name="Module" kind="asd:module" >
< pathParameter name="asd:implementation"
↵ value="Impl" >< /pathParameter >
< pathParameter name="asd:dataSet"
↵ value="Data" >< /pathParameter >
</ pathNode >
↵
< pathNode name="myProduct" kind="asd:element" ></ pathNode >
< /modelLocation >
< modelKind kind ="variable" visibility ="private" ></modelKind>
↵
< modelType type="continuous" >
< valueRange min="-2147483648.0" max="2147483647.0" >< /valueRange >
↵
< /modelType >
< annotation >
< ix:documentation xmlns=
"http://www.w3.org/1999/xhtml" lang="en-US">
This is variable < i >myProduct< /i > of continuous type.
< /ix:documentation >
↵
< /annotation >
< /modelOrigin >
< implementation >
< conversionRef name="ident" >< /conversionRef >
< valueRange min="-2147483648" max="2147483647"> < /valueRange >
↵
< saturation value="true" resolution="reduce"
↵ assignment="true" >< /saturation >
↵
↵
< zeroExcluded value="false" >< /zeroExcluded >
< /implementation >
< usage measurement="true" virtual="false" variant="false" >
< address kind="pseudo" >
< BLOB kind="KP_BLOB" device="E_TARGET" >
<![CDATA[2 1001 1 1000 0]]>< /BLOB >
< /address >
< /usage >
< /dataElement >
↵
↵
< dataElement interfaceKind="export">
< dataCInterface identifier=
"ASDSIMPLEMODEL_IMPL_ClassObj.Module-> myPar->val">
↵
↵
< type >< typeRef name="real64" >< /typeRef >< /type >
INTECRIO V4.6 - User’s Guide
ETAS SCOOP and SCOOP-IX
< fileOrigin name="MODULEM.c" lines="23" >
< /fileOrigin >
↵
< initValue value="3.2" />
< /dataCInterface >
< modelOrigin identifier="ASDSimpleModel.
Module.myPar">
↵
< name >myPar< /name >
< modelLink href="ASDSimpleModel.Module.myPar"
↵
> < /modelLink >
↵
< modelLocation >
< pathNode name="Module" kind="asd:module">
< pathParameter name=
"asd:implementation" value="Impl" >
< /pathParameter >
< pathParameter name=
"asd:dataSet" value="Data" >
< /pathParameter >
↵
↵
↵
< /pathNode >
< pathNode name="myPar" kind="asd:element" >< /pathNode >
< /modelLocation >
< modelKind kind="parameter" visibility="private" >< /modelKind >
< modelType type="continuous" >< /modelType >
↵
< annotation >
< ix:documentation xmlns=
"http://www.w3.org/1999/xhtml" lang="en-US">
This is parameter < i >myPar< /i > of continuous type.
< /ix:documentation >
< /annotation >
< /modelOrigin >
< implementation >
↵
< conversionRef name="ident" >< /conversionRef >
< valueRange min="-1.e+037" max="1.e+037" >
< /valueRange >
< zeroExcluded value="false" ></ zeroExcluded >
↵
< /implementation >
< usage calibration="true" virtual="false" variant="false" >
< address kind="pseudo" >
< BLOB kind="KP_BLOB" device="E_TARGET"
><![CDATA[2 1001 1 1000 1]]>< /BLOB >
< /address >
< /usage >
↵
↵
↵
↵
INTECRIO V4.6 - User’s Guide 135
136
SCOOP and SCOOP-IX ETAS
< /dataElement >
< functionElement interfaceKind ="export">
< functionCInterface identifier=
"MODULE_IMPL_compute">
< signature >
< return >
< type >< void />< /type >
< /return >
< void />
< /signature >
< fileOrigin name="MODULEM.c" >< /fileOrigin >
< /functionCInterface >
< modelOrigin identifier ="Module.compute">
< name >compute< /name >
↵
< modelLink href="Module.compute" />
< modelLocation >
< pathNode name="Module" kind="asd:module">
< pathParameter name="asd:implementation"
↵ value="Impl" >< /pathParameter >
< pathParameter name="asd:dataSet" value="Data" >< /pathParameter >
< /pathNode >
< pathNode name="compute" kind="asd:process" >
< /pathNode >
< /modelLocation >
< modelKind kind ="process" visibility ="public" > < /modelKind >
< runTimeInfo >
< FPUUsage value="true" >< /FPUUsage >
↵
↵
< TerminateTaskUsage value="false" >
< /TerminateTaskUsage >
< messageAccess >
< message identifier=
"MODULE_IMPL_ClassObj.Out1->val" send ="true" >< /message >
< /messageAccess >
< resourceAccess >< /resourceAccess >
↵
↵
< constraint >
< period value="0.01" ></period>
< execution trigger ="timer" priority ="0" >
↵
</execution>
< scheduling mode="preemptive" >
< scheduling>
↵
< /constraint >
< /runTimeInfo >
INTECRIO V4.6 - User’s Guide
ETAS SCOOP and SCOOP-IX
< annotation >
< ix:documentation xmlns=
↵
"http://www.w3.org/1999/xhtml">
This is process < i >compute< /i > of module
↵
< i >Module< /i >.
< /ix:documentation >
< /annotation >
< /modelOrigin >
< /functionElement >
< /interface >
< /module >
INTECRIO V4.6 - User’s Guide 137
138
Modeling Hints ETAS
6 Modeling Hints
This chapter provides an overview of the modeling philosophy of INTECRIO and describes how the behavioral modeling tools are used in conjunction with INTEC-
RIO.
This chapter does not intend to provide the complete instructions for creating an effective executable model.
6.1
Modeling for INTECRIO
If you create a model to be integrated with INTECRIO, the model itself does not contain any target-dependent information. The configuration of the operating system and the hardware configuration (e.g. assignment of processes to tasks or mapping of signals to an A/D board) are performed with INTECRIO.
A software module is the unit that can be imported in INTECRIO. It corresponds exactly to one SCOOP-IX description. In Simulink, this unit is a complete model that can contain any number of subsystems. As a special case, you can also generate code for a subsystem. This is treated as if it were a complete model. In
ASCET, a complete project is considered to be the unit that can be imported. It can contain any number of classes and modules.
Several models can be imported in INTECRIO as software modules. The inputs and outputs can be connected with each other and with physical I/O systems.
These connections can be changed dynamically, i.e. during the running experiment. A limitation is that these connections must be scalar. Vector connections can be measured as a whole, but only connected element by element in INTEC-
RIO.
Several software modules with their connections, a hardware system and an OS configuration form a system project – the unit for which INTECRIO can generate executable code (an
*.a2l.cod
file).
6.2
Modeling with Simulink
M ATLAB
/Simulink connectivity (see section 4.1) supports M
ATLAB® /Simulink ® with versions R2009a – R2015b and their related service packs known at the time of the INTECRIO V4.6 release.
Tip
INTECRIO supports the 32 bit and 64bit versions of M ATLAB /Simulink.
Unsupported M ATLAB /Simulink versions cannot be used to create code for use with INTECRIO.
Model code created with M ATLAB /Simulink R2006b – R2008b can still be imported and integrated in INTECRIO V4.6. However, back animation is not available for such a model.
During the installation of M ATLAB /Simulink connectivity, the M ATLAB /Simulink installation is adjusted so that M ATLAB /Simulink can interact with INTECRIO.
The following functions offered by Simulink and Real-Time Workshop ® (RTW) /
RTW Embedded Coder TM or M ATLAB
® ded Coder TM ) are supported:
Coder TM + Simulink ® Coder TM (+ Embed-
INTECRIO V4.6 - User’s Guide
ETAS Modeling Hints
• Almost all of the blocks supplied with Simulink
(except the blocks
To File
,
From File
,
To Workspace
and
From
Workspace
because they are not directly applicable to rapid prototyping targets)
Only 1-D and 2-D lookup tables (but no higher-dimensional lookup tables) can be available as curve or map CHARACTERISTIC elements in the
ASAM-MCD-2MC file.
• Different scanning times
• Single-tasking or multitasking (see Simulink documentation)
• Models containing continuous states (as well as all integration methods with fixed step size)
• Inlining of parameters and all the remaining optimizations offered by the
RTW / RTW Embedded Coder or M ATLAB Coder + Simulink Coder (+
Embedded Coder)
• The model verification blocks supplied with Simulink (model verification at runtime)
• Full fixed-point support (any data types with random scaling)
• User-defined S functions (no inlining, wrapper inlining, full inlining)
• Models with Stateflow ® diagrams (R2010b or lower: if the Stateflow ®
Coder TM is installed)
• External mode
• Model referencing
Modeling with Simulink for INTECRIO is based on the RTW/RTW Embedded
Coder or M ATLAB Coder+Simulink Coder/Embedded Coder code generation. By providing the INTECRIO Real-Time Target (IRT) and the INTECRIO Embedded
Coder Real-Time Target (IER), code generation can be adjusted to the requirements of INTECRIO. During the installation of the M ATLAB /Simulink interfacing, the path to the IRT or IER and to INTECRIO-specific blocks are added to the M AT -
LAB path settings of he user.
The modeling is carried out according to the instructions in the documentation of Simulink and the various coders (R2011a or higher: M ATLAB Coder+Simulink
Coder/Embedded Coder, R2010b or lower: RTW/RTW Embedded Coder), only target-dependent blocks of third parties must be avoided. IRT or IER must be selected as the target for the code generation.
INTECRIO V4.6 - User’s Guide 139
Modeling Hints ETAS
Details about modeling with M ATLAB /Simulink and about the joint use of M ATLAB /
Simulink and INTECRIO can be found in the INTECRIO section in the M ATLAB /
Simulink online help viewer.
140
6.3
Modeling with ASCET
An ASCET project is considered to be the unit that is imported in INTECRIO. The
OS configuration can partly be performed in ASCET, although this is not mandatory.
Details about modeling with ASCET and about the joint use of ASCET and INTEC-
RIO can be found in the ASCET online help (V6.3 and higher) or in the INTEC-
RIO-ASC and ASCET-RP documentation (V6.2 and lower).
6.4
Integration of User Code
If you want to import code in INTECRIO that is written by the user, a SCOOP-IX description must be created manually. It must contain the necessary include instructions as well as descriptions of the processes and values that you want to measure and calibrate.
6.5
Integrating GT-Power/GT-SUITE Models in INTECRIO
The content of this section was tested with the following setups:
• Windows ® 7 (64bit), INTECRIO V4.6, GT-Power 7.4, M ATLAB /Simulink
R2012a
This section is valid for GT-SUITE up to V7.4.
It is expected that M ATLAB /Simulink and INTECRIO are already installed on your machine.
Back animation is not supported for GT-SUITE systems.
INTECRIO V4.6 - User’s Guide
ETAS Modeling Hints
6.5.1
Copying Example Files
You do not need a complete GT-SUITE installation, only the files that can be found in the
RealTime
folder below the
$GTIHOME
folder (e.g., in
C:\Program Files\GTI\v7.1.0\simulink\RealTime
). This is called a limited installation as with this installation you are only able to run a simulation in Simulink, to build code & SCOOP-IX from Simulink Coder (R2011a or higher) or Realtime Workshop (RTW; R2010b or lower) and to build/run a system in INTECRIO and INCA.
By default, the
...\simulink\RealTime\GTSuiteRT
folder does not contain all necessary files after installation. Users who have the GT-SUITE RT license can obtain the complete contents from the GTI web site 1 . For more information, contact the GTI support ( [email protected]
).
In addition, you can use the files from
Model_for_INTECRIO.7z
as a first example. You can copy these files to any place on your file system (in the following, this place is called
Model_for_INTECRIO
).
6.5.2
Handling Multiple GT-SUITE Installations
If you need to handle several GT-SUITE installations because you work with
GT-SUITE models from different GT-SUITE versions, it is useful to create a folder structure as follows.
Fig. 6-1 GT-SUITE folder structure
Then copy the following folder structure of each GT-SUITE version to the respective
7.x
folder.
Fig. 6-2 simulink
subfolder
Finally, copy the simulink
subfolder (with all sub-folders etc.) from the
GT-SUITE version that you want to use into the current
The folder
GTI\current
will be used as baseDir
(used in M ATLAB ) and
$GT_LIBS
(used for Windows path etc.).
Each time when you want to change your GT-SUITE version, you need to copy the corresponding simulink
folder into current
. With that, there is no need to change/modify the Windows system path variable every time.
1. see http://www.gtisoft.com/
INTECRIO V4.6 - User’s Guide 141
Modeling Hints
The result might look as follows:
ETAS
6.5.3
Preparing the M
ATLAB
/Simulink Environment
In M ATLAB /Simulink, it can be necessary to add paths to the
SIMULINK
environment which might look as follows: baseDir = 'C:\GTI\current' addpath (strcat(baseDir,'\simulink\RealTime\sfunction')) addpath (strcat(baseDir,'\simulink\RealTime\src'))
In the
Model_for_INTECRIO
folder, you find
GTandSimulink_init.m
, a file that helps you to apply the above-mentioned paths. You must adapt the baseDir
variable to the correct location where you have put the GT-SUITE RT libraries and then run the m file.
Select File → Set Path to verify whether the paths are added or not.
142 INTECRIO V4.6 - User’s Guide
ETAS Modeling Hints
6.5.4
Checking the Simulink/GT-SUITE Model
You have to check that the Simulink model including the GT-SUITE RT model can b e s i m u l a t e d u n d e r S i m u l i n k . T o d o s o , o p e n t h e
* . m d l
f i l e
(
Motormodell_2008a.mdl
) and start the Simulink simulation.
Fig. 6-3 Simulink model
Stop the simulation, right-click on the GT-SUITE RT block (in Fig. 6-3:
GT-SUITE-RT Model
) and select S-Function Parameters from the context menu.
INTECRIO V4.6 - User’s Guide 143
Modeling Hints ETAS
The "Function Block Parameters" dialog window opens. To check whether the paths are correct, click on Edit . This button should open the corresponding C file
( gtsuitesl71rt.c
).
If no editor like the following one opens, the paths are wrong, and further code generation and build will fail.
144 INTECRIO V4.6 - User’s Guide
ETAS Modeling Hints
To generate the code for use with INTECRIO and INCA, you have to select the
INTECRIO target ( irt.tlc
) in the RTW (M ATLAB /Simulink R2010b or lower) or
Simulink Coder (M ATLAB /Simulink R2011a or higher).
In addition, you have to go to the "Custom Code" node and add the name of the GT-SUITE RT library ( libgtcfd.lib
), which can be found in the src
folder
(
$GT_LIBS
) of the GT-SUITE RT libraries.
INTECRIO V4.6 - User’s Guide 145
Modeling Hints ETAS
Now you can use <C TRL > + < B > or Tools → Real-Time Workshop or Code
Generation or Code → C/C++ 1 → Build Model to generate (build) the C code etc. you will import to INTECRIO.
6.5.5
Building in INTECRIO
First, you have to import the generated
*.six
file into INTECRIO and create a virtual prototyping system with this. For the INTECRIO build, you have to add the compiler macro
PCDLL
. In INTECRIO V4.2 and higher, this can be done via the
GUI in the properties of a system.
146
1. Real-Time Workshop : M ATLAB /Simulink R2010b or lower
Code Generation : M ATLAB /Simulink R2011a – R2012a
Code → C/C++ :M ATLAB /Simulink R2012b or higher
INTECRIO V4.6 - User’s Guide
ETAS Modeling Hints
When using an older INTECRIO version, you have to add this macro (blue line) manually to the
*.six
file:
...
<codeInfo>
...
<target>
...
<tool ...>
<configuration>
...
<option kind="macroDefine" name="RT" />
<option kind="macroDefine" name="PCDLL" />
<option kind="macroDefine" name="NUMST">1</option>
...
</coniguration>
</tool>
<target>
<codeInfo>
...
Now run the INTECRIO build process.
Tip
When the build fails (example error message:
GNU_GCC_LINKER:
Motormodell_2008a1\Motormodell_2008a1.a(gtsuitesl71rt.o
)(.text+0xb8):gtsuitesl71rt.c: undefined reference to
`rt_mxGetString'
), it is necessary to copy rt_matrx.c
manually to
Model_for_INTECRIO\Motormodell_2008a_irt_rtw\external\ rtw\c\src
.
rt_matrx.c
can be found at, e.g.,
C:\Program Files\MATLAB\
R2008b\rtw\c\src\rt_matrx.c
.
6.5.6
Preparation for Experiment with INCA or INTECRIO
This has been tested with
• INCA 7.0 / HF10 + INCA-EIP 7.0.3,
• ETAS Experiment Environment 3.3.1,
• INCA 7.1.6 + INCA-EIP 7.1.6,
• ETAS Experiment Environment 3.4.1/1
First, you need to add the paths of the GTI-Soft DLLs to the Windows path variable. The additional path should look as follows:
C:\GTI\current\simulink\RealTime\GTSuiteRT;
Or, based on your base folder
$GT_LIBS
, you need to add the following paths:
INTECRIO V4.6 - User’s Guide 147
Modeling Hints ETAS
$GT_LIBS\simulink\RealTime\GTSuiteRT;
Tip
If the path contains spaces, include the path in double quotes (
" <path with blanks> "
).
You may have to restart your computer for the changes to become effective.
Second, copy the
*.dat
file (e.g.,
Model_for_INTECRIO\GTandSimulink.dat
) from the GT-Model into the target server directory used for the experiment (e.g.
C:\ETAS\ETASShared10\TgtSvr
).
The log files generated by the GT-Model (e.g., error.out
) are written into this directory, too.
To find out which target server is used:
• Windows 7:
• Start the Windows Task Manager.
• Go to the "Processes" tab.
• Right-click the trgsrv.exe
process and select
Open File Location from the context menu.
The folder of the target server you are using opens.
148 INTECRIO V4.6 - User’s Guide
ETAS Bypass Concept
7 Bypass Concept
7.1
ETK Bypass Concept Description
With an ETK equipped ECU, the ECU code must be prepared to set up data structures and communication with the ETK to enable communication between the rapid prototyping system used for the ETK bypass and the ECU itself.
Independent of the ECU implementation of these drivers, some safety issues common to the concept of the bypass must be considered.
7.2
Bypass Input
Like for measurement, the Distab13 (and Distab12 for hook-based bypass) mechanism is used to provide ECU variables as inputs for the bypass.
The DIS play TAB le for the Distab13 contains a sorted list of addresses of variables in the ETK Flash. 8, 4, 2 and 1 byte values are supported. The addresses are ordered corresponding to the size of the values they point to. The ECU driver parses the table and writes the contents of the addresses to a table of return values in the ETK RAM. This table is ordered in the same manner as the address list: first, all 8 byte values, then the 4 byte values, etc.
With this approach, INCA and INTECRIO are given access to values of the internal memory of the microcontroller. Also, collecting the data in a table allows using block modes for transferring the data to the PC.
Fig. 7-1 gives an overview on the data layout for Distab13.
active unused unused unused
# of 8 bytes # of 4 bytes
# of 2 bytes # of 1 bytes address list
64bit values
32bit values
16bit values
8bit values
ETK Flash
ETK RAM
Fig. 7-1 Distab13 data structure
For each bypass raster that contains hooks for the hook-based bypass, an instance of the Distab is created and a Distab process is called. For the servicebased bypass, one instance of the Distab data structure exists for each trigger where a service is provided and configured to read ECU values as input for the bypass calculation.
For the hook-based bypass, the number and name of Distabs implemented in the
ECU code, and their size, e.g. the number of bytes per channel, is set by the ECU software setup and documented in the A2L description.
For service-based bypass, all tables are allocated dynamically in a given working memory.
INTECRIO V4.6 - User’s Guide 149
150
Bypass Concept ETAS
7.3
Hook-Based Bypass
Classical
For the classical hook-based bypass , the input values of the bypass are gathered with the same Distab13 mechanism as the measurements. After the bypass input data is written to the ETK RAM, the bypass calculation is triggered. In addition, a channel for writing back bypass results to the ETK where they can be retrieved by the ECU is introduced.
For each bypass input channel, an output channel is provided. The size of these channels, as well as their names, also have to be documented in the A2L description. The prototyping tool (INTECRIO or ASCET-RP) can define the number of variables written back to the ECU, depending on the bypass experiment setup.
Each variable written to by the bypass must be prepared in the ECU software by applying a hook to prevent the ECU from writing to this value if the bypass is active. The hook code is specific to the ECU and the variable it is applied to. No service is provided within this sample implementation for this task. The values prepared have to be documented in the A2L file by an
I F _ D A T A
ASAP1B_BYPASS
description.
The following figure describes the hook-based bypass principle. The hook indicates the possibility to toggle between the results of the original function (Fn) and the bypass function (Fn*).
Fn*
Bypass
Fn hoo k a
ECU
time
Fig. 7-2 Hook-Based Bypass: Principle
With Distab17
In connection with Distab17, the concept of service point configuration extends to the hook-based bypass. In this case, the hook-based bypass (HBB) is integrated with the service-based bypass (SBB): For hooked service points, the new signal values calculated in the rapid prototyping system are transferred to the ECU software by dedicated hook codes in the ECU functions instead of generically in a service point write action. Hooked service points are supported as of Distab17.
INTECRIO V4.6 - User’s Guide
ETAS Bypass Concept
• In the following illustration, Fn denotes the original function that runs on the ECU.
Rapid-Prototyping System
Hook labels
SOURCE_ID
BUFFER-OFFSET
Send data table
Buffer 1
Buffer 2
r pre action hooked service point
Fn
bypass value internally calculated value ECU
Fig. 7-3 Bypass with hooked service points
• Prior to the execution of the original function that runs on the ECU, hooked service points can be used to receive data from the ECU to the rapid prototyping system via a read or receive pre-action. The associated hook codes are usually implemented at the end of the original function.
The hooks receive their source (i.e. SOURCE_ID) and offset (i.e.
BUFFER_OFFSET) information from the associated hook labels.
• During the execution of the original function in the ECU, the rapid prototyping system writes data to a double-buffered send data table that can be accessed by these hooks in the original function. The two buffers are used alternately. Either the resulting bypass value or the value calculated internally by the original function is used.
7.4
Service-Based Bypass
Tip
INTECRIO does not support service-based bypass on an ETK with 8 Mbit/s.
For the service-based bypass , both the input values and the output values of the bypass function are transmitted with the same Distab13 mechanism. After the bypass input data is written to the ETK RAM, the bypass calculation is triggered.
In addition, a channel for writing back bypass results to the ETK where they can be retrieved by the ECU is introduced. Here, each bypassed ECU process uses and calls its own Distab.
This service also contains an inverted Distab mechanism to write back bypass outputs to the ECU. The ECU does not need to apply hooks to the variables written to, since the service simply overwrites the values with the bypass outputs.
INTECRIO sets up a Distab-like sorted address table with the addresses of the
ECU variables to be written to, and writes the corresponding values in a table of
INTECRIO V4.6 - User’s Guide 151
152
Bypass Concept ETAS the ETK Flash. The part of the ECU service that writes the bypass outputs to the
ECU parses the address table and gets the corresponding values from the data table and writes the values to the ECU addresses.
The following figure describes the service-based bypass principle.
Fn*
Bypass
Fn
ECU
time
Fig. 7-4 Service-Based Bypass: Principle (The dashed line indicates that bypass data can be written back at a later time as well.)
INTECRIO V4.6 supports several versions of service-based bypass (SBB). Tab. 7-1
lists the supported SBB versions for each target (+: supported, –: not supported),
and Tab. 7-2 lists the AML versions available in the SBB versions.
ES1000 / ES1232 / ETK
ES 910.2 / supported ETKs
ES 910.3 / supported ETKs
SBB V2.0
+
+
+
SBB V2.1
–
+
+
SBB V3.*
–
–
+
INTECRIO does not support service-based bypass on an ETK with 8 Mbit/s.
Tab. 7-1 Supported SBB versions
SBB version
V2.0 + V3.0
V2.1
V3.1
supported AML versions
ETK AML 1.2.0 – 1.7.0
XETK AML
SBB AML
≥ 1.0.0
≥ 2.0.0
ETK AML
XETK AML
SBB AML
ETK AML not supported
≥ 2.0.0
≥ 3.1.1
not supported
XETK AML
SBB AML
≥ 2.0.0
≥ 3.1.0
Tab. 7-2 SBB versions and AML versions supported Distab types
Distab13 - Distab16
Distab17
Distab17
INTECRIO V4.6 - User’s Guide
ETAS Bypass Concept
7.5
Safety Considerations
With calculating a bypass function on a rapid prototyping system and feeding data back into the ECU, the same care needs to be taken for development and use of bypass software as for ECU software. The bypass output may directly or indirectly influence the output channels of the ECU. The same applies, of course, if the rapid prototyping system uses own output channels.
Thus, it is highly recommended that the bypass functions include range checks and validations algorithms for the bypass outputs.
7.5.1
Bypass Input Data
To perform proper calculations, the bypass obviously needs consistent and valid input data. The ECU software must ensure this and prevent activation of the bypass if the ECU software detects incorrect or invalid inputs. This also includes
ECU states like initialization and afterrun, or error modes the ECU might run in.
In other words, activation of and data transfer to the bypass must be covered by the safety mechanisms of the ECU.
7.5.2
Bypass Calculation
The ECU software must be aware whether the bypass is active and must provide measures to react on bypass failures, for example missing calculations or unexpected shut off of the bypass system.
Failsafe measures might be using the alternative output values of the bypassed
ECU functions, using constant fallback values, or even resetting the ECU, depending on the bypassed ECU function. This is entirely under responsibility of the ECU provider who integrates the bypass drivers.
Some implementations of the ECU bypass drivers, as for the service-based bypass, allow the deactivation of the bypassed ECU function by the bypass user.
In this case, the results of the bypassed ECU function obviously cannot be used as fallback. This must be considered when setting up a safety strategy.
7.5.3
Bypass Output Data
The ECU provider must guarantee that any value sent back by the bypass system leads to a predictable behavior of the ECU – the bypass output values must undergo the same range check and validation as the values calculated within the bypass.
As said before, the implementation of the ECU drivers must, in any case, ensure that bypass failures can be detected by the ECU and valid and safe fallback values are available at any time.
7.5.4
Message Copies
If the ECU software contains message copies, the bypass must be aware of them.
The usual implementations of the hook-based bypass are an exception to that rule. Here, the hooks (and thus the messages written to) are known before compilation, so that the hook code can take care of and use message copies if needed—individual code and addresses are used at each hook.
INTECRIO V4.6 - User’s Guide 153
154
Bypass Concept ETAS
With the service-based bypass , users cannot choose variables and decide which message to write to before they set up the bypass experiment in INTECRIO. Thus, the services in the ECU are generic code and do not know about specific message copies.
This requires two steps:
1. The ECU software provider must provide this message copy information in the A2L file (usually in encrypted and password-protected form).
2. If the message copy information is encrypted, the user of the bypass system receives a password from the ECU software provider. He must enter this password to decrypt the information and use it for system configuration.
If one of these two steps is missing (usually a wrong password is entered), the bypass system has no knowledge of message copies and reads from / writes to the original variable address, as it is declared in the
MEASUREMENT
declaration of the A2L file. For receive variables, this yields old data values. For send variables, the data value written by the bypass model may be overwritten by other parts of the ECU software. Both cases may cause bypass malfunction!
Another principal problem can arise with ECU software that contains message copies. The original code to create the message copies for an ECU task was based on the given message usage and generated appropriate code. By writing variable values into the ECU via bypass methods, the data flow changes, and a new or different message copy may become necessary. This can result in wrong variable values in the ECU software even at locations which are not directly related to the bypassed functions. Whether writing to a certain variable at a certain location (e.g. service point) may be dangerous or not, can be answered only by the ECU software supplier. This information cannot be declared in the A2L file.
7.6
Service-Based Bypass Specifics
Unlike the hook-based bypass where either the ECU or the bypass writes to the bypassed variable, the service-based bypass has an inherent possibility of data inconsistency, since both the ECU and the bypass write to the same value consecutively. Due to ECU real-time constraints, interrupts cannot be disabled to protect the sequence of writing the results of the ECU function and then writing the variable values of the bypass.
INTECRIO V4.6 - User’s Guide
ETAS Bypass Concept
So, if a preemptive task of higher priority interrupts the tasks containing the bypass service, it will see the ECU value instead of the bypass value. The probability of this inconsistency depends on the distance between the two writes.
Interrupting task
Bypass
Fn*
ECU
Fn
time
Fig. 7-5 Possible data inconsistency (the small arrows ( ing time for bypass results)
) indicate a wait-
A countermeasure to this problem is disabling the ECU function, so that only the bypass is writing to the bypassed ECU values (see below). Be aware that disabling the ECU function implies other safety constraints in case of bypass failures as discussed below.
7.6.1
Service Processes for the SBB Implemented as Service Functions
For SBB, the way of ECU implementation is to replace the ECU process to be bypassed by a container process that contains service function calls before and after it calls the original ECU process. This allows to call the ECU process under certain conditions only, e.g. to deactivate it in case of possible data consistency problems. To simulate the timing behavior of the disabled ECU process, a delay time can be configured.
Therefore, the suggested ECU implementation looks like this:
Fn*
Bypass
Fn
ECU
time
Fig. 7-6 Suggested SBB implementation
For setting up the bypass experiment in INTECRIO and implementing the service point in the ECU software as container process, a service point is defined as
INTECRIO V4.6 - User’s Guide 155
Bypass Concept ETAS
1. receiving data from the ECU (pre read action),
2. waiting for data to be sent (a time-out is defined),
3. sending data to the ECU (pre write action),
4. conditionally executing the original ECU process,
5. receiving data from the ECU (post read action),
6. waiting for data to be sent (a time-out is defined),
7. sending data to the ECU (post write action).
Each pre and post action can be freely configured or activated / deactivated.
7.6.2
Controlling the ECU Behavior from INTECRIO
Upon setting up the INTECRIO experiment, an initial setting of the control variables can be done in INTECRIO. These values are written to the ETK on experiment initialization.
The ECU function can be controlled by the INTECRIO user in several ways (if the
ECU drivers also provide this functionality):
• The ECU function can be deactivated in the service point editor of INTEC-
RIO (
• The detection of a bypass error can be defined
• The bypass error behavior of the ECU code can be influenced
156
Fig. 7-7 Controlling ECU function execution from INTECRIO
(The columns "Cluster Group" and "Cluster" are only available for
SBB V3.*.
The "Raster Usage" display is only available for SBB V2.*.)
7.6.3
OS Configuration for Service-Based Bypass V3
This section explains some ways how to configure the operating system for a system project with service-based bypass V3.
Restrictions
The following restrictions are valid for OS configuration of a system project with service-based bypass V3:
INTECRIO V4.6 - User’s Guide
ETAS Bypass Concept
• A read action (represented by a receive signal group, ) is allowed only in an INTECRIO software task where the read action is mapped both as action and as event.
Since an event can be mapped to only one task, this means that a read action can be mapped to only one INTECRIO software task.
• Read actions cannot be assigned to timer, init, or exit tasks, or ISR.
• Up to 247 read actions (255 minus 8 reserved for internal use) can be used per INTECRIO task priority and thus per ETK trigger.
• The currently used RTA-OSEK restricts the number of tasks available for service-based bypass to a maximum of 253 (the total number of available tasks is 256, and 3 system-internal tasks are necessary in any case).
• No restrictions apply to write actions (represented by send signal groups,
).
– Write actions can be mapped to all kinds of tasks (software, timer, init, exit, ISR).
– A single INTECRIO task can contain write actions from different service points in different service point clusters.
Fig. 7-10 shows an example for an INTECRIO task that contains one read action
and several write actions from various ECU tasks.
Classical ECU Function Bypass
In a classical ECU function bypass, the pre read action and the post write action of a service point are activated. Both actions are mapped to the same INTECRIO task.
SW task A SW task B
Read_F1
F1'
Write_F1
Read_F3
F3'
Write_F3
F1 F2 F3 F4 pre post
SP 1 SP 2 SP 3 SP 4
Fig. 7-8 Example: classical bypass
To achieve this kind of OS configuration, the following steps are required:
1. Use the Auto Mapping feature of the OSC as a starting point.
With that, actions from different service points are mapped to different software tasks, and appropriate events are assigned. Software processes are mapped to timer, init or exit tasks.
2. In the OSC, move the software processes that replaces the ECU function of a certain service point to the INTECRIO software task that contains read and write action of that service point.
3. Remove empty tasks from the OS Configuration (optional).
INTECRIO V4.6 - User’s Guide 157
Bypass Concept ETAS
158
Fig. 7-9 OS configuration for a classical ECU function bypass
Bypass of an Entire ECU Functionality
One INTECRIO task may contain pre and post write actions from different service points and ECU tasks. This can be used to bypass the entire ECU functionality
(consisting of several processes in different ECU tasks), which minimizes the number of interrupts and thus latency. Read signals are not updated while the task runs on the rapid prototyping target. Partial results are sent to the ECU as fast as possible to ensure the currency of the values of other functions.
In the example shown in Fig. 7-10, service points SP 1 and SP 2 belong to a high-
priority ECU task A. Service point SP 3 belongs to a medium-priority ECU task B.
Service point SP n belongs to a low-priority ECU task C. The read action of SP 1 and the write actions of all service points are assigned to the same INTECRIO software task.
Read_F1
F1'
Write_F1
F2'
Write_F2
F3'
Write_F3
…
Fn’
Write_Fn
SW task
F1
SP 1
F2
SP 2
F3
SP 3
Fn
Fig. 7-10 Example: Bypass of an entire ECU functionality
SP n
ECU task A
ECU task B
ECU task C
INTECRIO V4.6 - User’s Guide
ETAS Bypass Concept
To achieve this kind of OS configuration, the following steps are required:
1. Use the Auto Mapping feature of the OSC as a starting point.
With that, actions from different service points are mapped to different software tasks, and appropriate events are assigned. Software processes are mapped to timer, init or exit tasks.
2. In the OSC, move the write actions (i.e. send signal groups) from the fastest timer task, where they were mapped automatically, to the INTECRIO software task that contains the read action of SP 1.
You may use the "Hardware" tab of the OSC to search for a particular signal group, and the Search context menu of the group to locate it in the
OS configuration tree view.
3. Move the software processes to the same INTECRIO software task as the write actions.
You may use the "Software" tab of the OSC to search for a particular process, and the Search context menu of the process to locate it in the OS configuration tree view.
4. Remove empty tasks from the OS Configuration (optional).
Fig. 7-11 OS configuration for the bypass of an entire ECU functionality
Read and Write Actions of the Same Service Point in Different Rasters
The read action and the write action of the same service point can be configured independently, they can be assigned to different tasks with different events or periodicities.
INTECRIO V4.6 - User’s Guide 159
160
Bypass Concept ETAS
Fig. 7-12 shows two examples. On the left (A), a higher-priority model task is
assigned a higher ETK raster priority for the write action. On the right (B), a lower priority model task is assigned a lower ETK raster priority for the write action.
...
Write_F1
(A) (B) INTECRIO task priority higher task priority ïƒ higher ETK raster priority
Read_F1
...
Read_F1
...
...
Write_F1 lower task priority ïƒ lower ETK raster priority
F1 F1
Service Point Service Point
Fig. 7-12 Examples: Read and Write actions in different rasters
To achieve this kind of OS configuration, the following steps are required:
1. For a given service point, activate one read action and a write action after the read action.
2. Manual configuration:
– Create a software task with appropriate priority, assign the read action to the
Actions
folder and the event of the read action to the
Events
folder of this task.
– Create another task (e.g., a timer task) with appropriate priority and assign the write action to the
Actions
folder of this task.
Or
3. Use the Auto Mapping feature of the OSC as a starting point:
– Perform Auto Mapping .
Auto Mapping maps both actions of the service point to the same software task.
– Move the write action to the INTECRIO task you want to use.
4. Map the software processes to appropriate tasks.
5. Remove empty tasks from the OS Configuration (optional).
INTECRIO V4.6 - User’s Guide
ETAS Bypass Concept
Fig. 7-13 OS configuration (incomplete) for a bypass with read and write actions of a service point in different tasks
ECU-Synchronous Write-Back
The idea of ECU-synchronous write-back is to calculate results at the earliest possible stage on the rapid prototyping system (E-target) so it can be retrieved by the
ECU at the right point-in-time.
Fig. 7-14 illustrates how service points can be used for ECU-synchronous write-
back. Following the pre-action Read_F1 of service point SP 1, the result, F3', is available in the rapid prototyping system, but not in the ECU. At the right point in time, service point SP 3 fetches F3' and writes the result to the ECU as F3. Note that the (Read_F3) action is a "dummy" action that merely serves to release the
ETK channel, and that no signal has to be selected for that dummy signal group.
SW task A SW task B
Read_F1
...
F3'
(Read_F3)
Write_F3
F1 F3 pre post
SP 1 SP 3
Fig. 7-14 Example: ECU-synchronous write-back
To achieve this kind of OS configuration, the following steps are required:
1. Use the Auto Mapping feature of the OSC as a starting point.
With that, actions from different service points are mapped to different software tasks, and appropriate events are assigned. Software processes are mapped to timer, init or exit tasks.
INTECRIO V4.6 - User’s Guide 161
Bypass Concept ETAS
2. In the OSC, move the F3’ software process to the INTECRIO software task assigned to the read action of SP 1.
3. Remove empty tasks from the OS Configuration (optional).
162
Fig. 7-15 OS configuration (incomplete) for a bypass with read and write actions of a service point in different tasks
For SBB V3 and higher, the results of OS mapping and trigger assignment in the build process are reported in an XML log file. The file is stored in the workspace log directory, it is named
<system name> _ETKSBBV3_TriggerInfo.xml
.
This file lists, for each service-point action used in the system project, the name
(
TASKNAME
) and priority (
TASKPRIO
) of the task where the signal group is executed, as well as number (
TRGNUMBER
) and priority (
RASTERPRIO
) of the ETK trigger with which the signal group data will be transferred.
Example:
<TriggerInfo
SIGNALGROUPNAME=
"ETK_Bypass.MySP_1.MySP_1_before_receive_from_ECU"
RASTERPRIO ="8"
TASKNAME ="M_ETK_Bypass_MySP_1_before_re"
TASKPRIO ="195"
TRGNUMBER ="28"
TRGFLAGADDR="a303efb8"
RAID="1"/>
This information is useful if the bypass system must be debugged.
7.6.4
Summary
The implementation and integration of the ECU drivers must take care of the following:
• As the service-based bypass only overwrites ECU values with bypass values without preventing the ECU from writing these values, there is a possibility of data inconsistency which can lead to unpredicted behavior of the
ECU.
INTECRIO V4.6 - User’s Guide
ETAS Bypass Concept
• INTECRIO provides a configuration variable to set the maximal number of tolerated lost cycles, e.g. how many ECU calculation cycles without receiving bypass values are tolerated before this is regarded as an error. But it is up to the provider of the ECU software to make sure missing bypass output values are detected.
• INTECRIO provides a configuration variable to set a specific error behavior
(if also supported by the ECU implementation). But it is up to the provider of the ECU software to make sure bypass failures or bypass deactivation can be detected by the ECU software! The configuration setting in the
INTECRIO GUI can then be used to choose between different provided error behaviors in the ECU.
• INTECRIO allows disabling the bypassed ECU process. In this case, no ECU values can be used as fallback values for bypass failures! It is up to the provider of the ECU software to make sure sensible data is written to the variables if both the ECU process and the bypass is disabled.
INTECRIO V4.6 - User’s Guide 163
Glossary ETAS
164
8 Glossary
This glossary contains explanations of the technical terms and abbreviations used in the INTECRIO documentation. While many terms are also used in a more general sense, this glossary specifically addresses the meaning of those terms as they are applied to INTECRIO.
The terms are listed in alphabetical order.
8.1
Abbreviations
ABS
A ntilock B raking S ystem
API
Programming interface for the application developer ( A pplication P rogramming I nterface).
ASAM-MCD
Working Group for Standardizing Automation and Measuring Systems, including the Working Groups Measuring, Calibrating, and Diagnostics
(German: A rbeitskreis zur S tandardisierung von A utomations- und M esssystemen, mit den Arbeitsgruppen M essen, C alibrieren und D iagnose)
ASAM-MCD-2MC
A file format used to describe the calibration variables and measured signals contained in the control unit software, and additional specific information designed to parameterize the experiment interface. ASAM-MCD-
2MC is used to import the information required for this into an experiment (A2L file).
INTECRIO V4.6 supports the ETK AML versions 1.1 (only hook-based bypass) or 1.2 – 1.7 (hook-based and service-based bypass), XETK AML versions 1.0.0 and higher (the first description of an ETK is read),
ASAP1B_Bypass AML V1.0 and higher, and SBB AML versions 2.0, 3.0 and
3.1.
ASCET
For further information, refer to http://www.asam.net
.
ETAS product family for the development of electronic control unit software. ASCET models can be imported in INTECRIO.
ASCET-MD
ASCET M odeling & D esign – the behavioral modeling tool of the ASCET product family.
ASCET-RP
AUTOSAR
Aut omotive O pen S ystem Ar chitecture; see http://www.autosar.org/
BMT
ASCET R apid P rototyping – the rapid prototyping tool of the ASCET product family.
B ehavioral M odeling T ool. The BMT can be used to edit, simulate and animate the behavior of models and generate the function code.
INTECRIO V4.6 - User’s Guide
ETAS Glossary
BSW
B asic s oft w are; provides communications, I/O, and other functionality that all software components are likely to require.
CANdb
CAN d ata b ase; CAN description file created with the CANdb data management program made by the company Vector Informatik.
INTECRIO V4.6 supports the CANdb versions V2.3 and higher.
CPU
Distab
C entral P rocessing U nit. In the context of INTECRIO, this refers to a single microcontroller.
Data exchange method, used in ETK bypass experiments for data exchange between experimental target and ECU.
INTECRIO V4.6 supports hook-based bypass with Distab 12 and higher
(XETK AML: Distab 13), as well as service-based bypass with Distab 13.
In combination with ES910.3 (or later ES910 models once they are available), INTECRIO V4.6 supports also bypass with Distab 17.
ECU
E lectronic C ontrol U nit; a small embedded computer system that consists
of a CPU and the associated periphery, where everything is usually located
in the same housing.
ERCOS EK
OSEK-compliant ETAS real-time operating system
ESP
E lectronic S tability P rogram
ETK emulator test probe (German: E mulatorT ast k opf)
FETK emulator test probe (ETK) for the ETAS ES89x ECU and Bus Interface Modules
FIBEX
Fi eld B us Ex change – an exchange format based on an XML schema which is used for descriptions of the complete in-vehicle communication network. FIBEX is defined for various network types (CAN, LIN, MOST,
FlexRay) and contains information about bus architecture, signals, properties of network nodes, etc.
The FIBEX file format is standardized by ASAM (Association for Standardization of Automation and Measuring Systems).
INTECRIO V4.6 supports the FIBEX baseline versions FIBEX V2.0.x and
V3.1.0; the latter with some restrictions (see the online help for details).
For further information, refer to http://www.asam.net
.
FIFO
F irst i n, f irst o ut
INTECRIO V4.6 - User’s Guide 165
166
Glossary ETAS
HBB h ookb ased b ypass
HC
H ardware C onfigurator
IER
I NTECRIO E mbedded Coder R eal-Time Target (RTW Embedded Coder or
Embedded Coder real-time target for importing Simulink model in INTEC-
RIO)
INCA
ETAS measuring, calibration and diagnostics system ( In tegrated C alibration and A cquisition Systems)
INCA-EIP
INCA add-on; allows access to the rapid prototyping (ES1130, ES1135,
ES910, RTPRO-PC) and virtual prototyping (VP-PC) targets for INCA.
INTECRIO-RP
INTECRIO R apid P rototyping package – provides connectivity to the rapid prototyping targets.
INTECRIO-VP
INTECRIO V irtual P rototyping package – provides connectivity to the virtual prototyping targets.
IRT
I NTECRIO R eal-Time T arget (RTW or Simulink Coder real-time target for importing Simulink model in INTECRIO)
LDF
L IN d escription f ile – a configuration file for a LIN controller.
INTECRIO V4.6 supports the LDF versions 1.3, 2.0 and 2.1.
LSB and lsb
L east S ignificant B yte (capital letters) or b it (small letters)
MDA
MSB and msb
M ost S ignificant B yte (capital letters) or b it (small letters)
OIL
M easure D ata A nalyzer program; an offline instrument by ETAS for displaying and analyzing saved measurement data.
O SEK I mplementation L anguage – as describing language for electronic control unit networks, it is an indirect part of the OSEK operating system.
OIL is used to describe static information of the electronic control unit network, such as communication connections and electronic control unit properties.
OS
O perating S ystem
INTECRIO V4.6 - User’s Guide
ETAS Glossary
OSC
OS configurator ( O perating S ystem C onfigurator)
OSEK
Working group for Open Systems for Electronics in Motor Vehicles (German: O ffene S ysteme für die E lektronik im K raftfahrzeug)
PDU
P rotocol d ata u nit; a data unit that contains payload and control information which is passed between the layers in a protocol stack.
In INTECRIO V4.6, a FlexRay PDU corresponds to a signal group.
RE
R unnable e ntity; a a piece of code in an SWC that is triggered by the RTE at runtime. It corresponds largely to the processes known in INTECRIO.
RTA-OSEK
ETAS real-time operating system; implements the AUTOSAR-OS V1.0
(SC-1) and OSEK/VDX OS V2.2.3 standards and is fully MISRA compliant.
RTA-OS
ETAS real-time operating system; implements the AUTOSAR R3.0 OS and
OSEK/VDX OS V2.2.3 standards and is fully MISRA compliant.
RTA-RTE
AUTOSAR runtime environment by ETAS
RTE
AUTOSAR runtime environment; provides the interface between software components, basic software, and operating systems.
RTIO
R ealT ime I nputO utput
RTPRO-PC
RTPRO-PC ( R ealT ime Pro totyping for PC ) allows the real-time execution of prototyping models on an off-the shelf notebook. After installation of
RTPRO-PC, the system can be used as a Windows ® -only computer or as a combined Windows / prototyping (= real-time) computer or as a pure realtime computer.
The real-time computer, or real-time node in combined mode is supported as ETAS experimental target. On the Windows node of the combined mode, standard Windows applications can be used with slightly less performance than in Windows-only mode.
RTW
R ealT ime W orkshop ® ; code generator of M ATLAB /Simulink R2010b or lower.
In M ATLAB /Simulink R2011a or higher, the RTW functionality is included in the Simulink Coder.
SBB s erviceb ased b ypass
INTECRIO V4.6 - User’s Guide 167
Glossary ETAS
168
SBC
Electrohydraulic brake system ( S ensotronic B rake C ontrol)
SCOOP
S ource Co de, O bjects, and P hysics
SCOOP-IX
SCOOP I nterface E x change language.
INTECRIO V4.6 supports SCOOP-IX versions V1.0, V1.1, V1.2 and V1.4.
SP s ervice p
SWC
Atomic AUTOSAR software component; the smallest non-dividable software unit in AUTOSAR.
UDP
U ser D atagram P rotocol
UML
U nified M odeling L anguage
VFB
V irtual f unction b us in AUTOSAR
XCP
Universal measurement and c alibration p rotocol; the x generalizes the various transportation layers that can be used.
INTECRIO V4.6 supports XCP version V1.0.
XETK emulator test probe (ETK) with ethernet interface
XML
E x tensible M arkup L anguage
8.2
Terms
Actuator
Executing hardware unit. It forms the physical interface between electronic signal processing and mechanics.
Application mode
An application mode is part of the operating system; it describes different possible states of a system, such as the application mode EEPROM programming mode, starting or normal operation.
AUTOSAR software component
Back animation
Animation of the model in BMT with measured values from the running experiment. Calibration variables can be calibrated from inside the BMT.
INTECRIO V4.6 - User’s Guide
ETAS Glossary
Basic software
Bypass experiment
In a bypass experiment, parts of an electronic control unit program are executed on the experimental target (ES1000, ES900 or RTPRO-PC). This requires a special hook in the code.
INTECRIO V4.6 supports several types of bypass experiments: XCP bypass on CAN or UDP, as well as hook-based and service-based ETK bypass.
Connection, dynamic
Connection between signal source and sink that can be changed at runtime without a new build process.
Connection, static
Connection between signal source and sink that cannot be changed at runtime.
Crossbar
Manages and controls the connections between modules, functions and hardware in a non-AUTOSAR environment.
Embedded Coder TM
; extends the capabilities provided by the Simulink Coder to support specification, integration, deployment, and testing of production applications on embedded targets.
Environment system
Environment systems are used to model the plant model for virtual prototyping. They are built out of modules and functions, the same way as software systems.
Event
An event is an (external) trigger that initiates an action of the operating system, such as a task.
Event interface
FlexRay
FlexRay is a scalable and fault tolerant communication system for highspeed and deterministic data exchange. FlexRay’s time-division multiplexing facilitates the design of modular or safety-related distributed systems.
Its high bandwidth of 10 MBaud on two channels helps to cope with the high network load caused by the increasing amount of innovative electronic systems in modern vehicles.
The communication system’s specifications are released by the FlexRay consortium which is widely supported by vehicle manufacturers and suppliers worldwide.
Fullpass experiment
In a fullpass experiment, the complete electronic control unit program is executed on the experimental target.
INTECRIO V4.6 - User’s Guide 169
170
Glossary ETAS
Function
A grouping object for software systems that does not feature its own functionality. Modules or functions are assembled and connected in a function; they are thus clearly arranged and can be easily reused.
Graphical framework
The window that displays after the start of INTECRIO. The different INTEC-
RIO components are integrated in the graphical framework.
Hardware system
A hardware system contains the complete description of a hardware topology, consisting of the descriptions of the associated ECUs (experimental targets) as well as the descriptions of the interfaces (bus systems) between the devices.
Integration
The convergence of model code, which may have been developed by different partners or with different tools, to control algorithm, the configuration of this algorithm for the hardware on which it is supposed to run, and finally the creation of an executable file.
Implementation
An implementation describes the conversion of the physical task definition
(of the model) into executable fixed-point code. An implementation consists of a (linear) conversion formula and a limiting interval for the model values.
INTECRIO
INTECRIO is a tool that combines, i.e. integrates, the parts of the control algorithm created with different behavioral modeling tools that allows for creating and configuring a hardware system and the connection of this hardware system with the control algorithm.
M ATLAB
®
High-performance language for technical calculations; contains mathematical calculations, visualization and programming in one environment.
M ATLAB
® Coder TM
Introduced in M ATLAB /Simulink R2011a; the code generator for M ATLAB code.
Module
A module in INTECRIO contains the generic description of a functionality for an electronic control unit. For example, it corresponds to an ASCET project or a Simulink model.
OS configurator and OSC
The task of the operating system configuration is carried out within
INTECRIO the OS configurator and the OSC editor. The OSC is part of the
OS configurator, an easy to handle editor for the operating system configuration that provides the user with a quick overview of the system and allows for editing the configuration in an application-oriented display.
INTECRIO V4.6 - User’s Guide
ETAS Glossary
Process
A process is a simultaneously executable functionality that is activated by the operating system. Processes are specified in modules and do not feature any arguments/inputs or result values/outputs.
Processor
Project Configurator
The project configurator is part of the integration platform of INTECRIO. It is used to specify software systems and system projects.
Project Integrator
The project integrator combines all the components of the system (modules and functions, hardware interfacing, OS configuration, etc.) into an executable file.
Prototype
Completely executable file for an experimental target system. Such a prototype shows the software functions in practical use – entirely with different goal directions and in a different appropriation.
Rapid prototyping
The execution of a software on an experimental target, i.e. a computer with an interface to the vehicle.
RTA-Trace
Software tracing tool that can monitor system behavior over a versatile interface to the ECU.
Real-Time Prototyping for PC
Real-Time Workshop ®
Real-Time Workshop ® Embedded Coder TM
In M ATLAB /Simulink R2010b or lower, an add-on for the R ealT ime W orkshop; extends the capabilities provided by the Real-Time Workshop to support specification, integration, deployment, and testing of production applications on embedded targets.
Runnable entity
Runtime environment
Sensor
Sensors convert a physical or chemical (usually nonelectrical) quantity into an electrical quantity.
Service point
A service point is an encapsulation of a process in the ECU software. It provides data transfer actions to and from the target system; these actions can be enabled and configured by the user.
INTECRIO V4.6 - User’s Guide 171
172
Glossary ETAS
Service point cluster
A group of service points that are executed in the ECU with the same priority (service points located in the same ECU task).
Service point cluster group
A group of service point clusters. The group contains all service points of all tasks that can potentially be invoked at the same time in the ECU.
Simulink ®
Tool for modeling, simulation and analysis of dynamic systems. The models can be imported in INTECRIO.
Simulink ® Coder TM
Introduced in M ATLAB /Simulink R2011a; the code generator for Simulink and Stateflow models. Requires the M ATLAB Coder.
Stateflow ®
Tool for modeling and simulation of complex event-controlled systems. It is seamlessly integrated in M ATLAB /Simulink.
Stateflow ® Coder TM
In M ATLAB /Simulink R2010b or lower, code generator for Stateflow. It is seamlessly integrated in M ATLAB /Simulink.
In M ATLAB /Simulink R2011a or higher, the Stateflow Coder functionality is included in the Simulink Coder.
Software system
A software system contains the generic parts of the ECU description: modules, functions and connections.
System project
A system project combines a hardware system, a software system, an environment system (if applicable), the mapping of the signals and the configuration of the operating system in a common project and allows for the generation of executable code.
Task
A task is an ordered collection of processes that can be activated by the operating system. Attributes of a task are its application modes, activation trigger, priority and modes of its scheduling. Upon activation, the processes of the task are executed in the specified order.
Validation
Process for the evaluation of a system or a component with the purpose of determining whether the application purpose or the user expectations are met. Therefore, the validation is the check whether the specification meets the user requirements, whether the user acceptance is reached by a function after all.
Verification
Process for evaluating a system or a component with the purpose of determining whether the results of a given development phase correspond to the specifications for this phase. Therefore, software verification is the check whether an implementation of the specification specified for the respective development step is sufficient.
INTECRIO V4.6 - User’s Guide
ETAS Glossary
Virtual prototyping
Function developers create virtual prototypes of electronic vehicle functions and test them on the PC.
Workspace
The workspace combines all the data generated while working with
INTECRIO. From the WS browser, i.e. the tree view of the workspace, you can call up all the components of INTECRIO.
X-Pass experiment
Mixture of bypass and fullpass experiment. The experimental target
(ES1000, ES900, RTPRO-PC) utilizes the ECU with bypass hooks as interface to the outside world.
INTECRIO V4.6 - User’s Guide 173
174
Appendix: The INCA Connector ETAS
9 Appendix: The INCA Connector
The INCA connector is an add-on product for INCA. When using an executable file created with INTECRIO for an INCA experiment, the INCA connector allows access to the M ATLAB /Simulink back animation, provided M ATLAB /Simulink is installed on your computer.
9.1
System Requirements
INCA version: The INCA connector requires that INCA V7.0 or higher is installed, together with a suitable version of INCA-EIP. Older versions are not supported.
Tip
INCA and INCA-EIP must be obtained separately, they are not part of the INCA connector. Without the installation of INCA and INCA-EIP, the INCA connector cannot be used.
M ATLAB /Simulink version: The INCA connector supports M ATLAB /Simulink with versions R2009a – R2015b and their related service packs known at the time of the INTECRIO V4.6 release. If several supported M ATLAB /Simulink versions are installed, all of them are supported at the same time.
Tip
INTECRIO supports the 64bit versions of M ATLAB /Simulink.
Unsupported M ATLAB /Simulink versions cannot be used to create code for use with INTECRIO.
Model code created with M ATLAB /Simulink R2006b – R2008b can still be imported and integrated in INTECRIO V4.6. However, back animation is not available for such a model.
9.2
Installation
You can only install the INCA connector if INTECRIO is not installed on your PC.
The same user privileges are required as for the installation of INTECRIO or INCA.
To start the installation:
• Insert the data carrier in the respective drive on your
PC.
• Open the
INCA-Connector
folder on the installation disk.
• Double-click the
INCA-Connector.exe
file.
• Follow the instructions on the monitor.
If INTECRIO is installed on your computer, the following message is displayed and the installation is aborted.
INTECRIO is installed. You already have the INCA-Connector functionality installed. Abort installation...
INTECRIO V4.6 - User’s Guide
ETAS Appendix: The INCA Connector
To connect the INCA connector and M ATLAB /Simulink:
After copying is completed, the "Association with M ATLAB " window opens displaying M ATLAB /Simulink installations available on your system for selection. You can select one of them or search for an installation manually.
• Select one or more of the existing M ATLAB /Simulink installations.
• Click OK .
The INCA connector is associated with the selected installations.
Or
• Click Cancel .
The association is not established, the installation of the INCA connector is aborted.
With that, the installation is concluded. Click OK to confirm the message „Installation successfully finished“.
You can change the M ATLAB /Simulink version associated with the INCA connector later. To do so, select Associate with Matlab from the INCA connector folder of the Windows start menu.
9.3
Working with the INCA Connector
The INCA connector contains everything required for a successful back animation of Simulink models during an INCA experiment, i.e., the connector provides the INTECRIO targets irt.tlc
and ier.tlc
in Simulink. It does not contain
INTECRIO code generation functionality.
INTECRIO V4.6 - User’s Guide 175
176
Appendix: The INCA Connector ETAS
Working with the INCA connector consists of two steps. Fig. 9-1 shows the sche-
matic procedure.
PC (Function Development)
M ATLAB /Simulink
INTECRIO
M ATLAB /Simulink Connectivity
INTECRIO
Integration Platform
INTECRIO
Experiment Environment
*.mdl
*.a2l
*.cod
PC (Measurement / Calibration)
M ATLAB /Simulink
INTECRIO
INCA Connector
INCA-EIP
INCA
RTPRO-
PC
RTPRO-
PC e.g.
ETK
Fig. 9-1 Integration of INCA connector in INTECRIO
In the first step, the Simulink model and the INTECRIO prototype are created
("PC (Function Development)" in Fig. 9-1). The requirements for back animation
must be considered during creation.
These works are described in the INTECRIO documentation. Special hints for
modeling in Simulink can be found in sections 4.1 "M ATLAB® /Simulink ® Connec-
tivity" and 6.2 "Modeling with Simulink" of the INTECRIO user’s guide, as well
as section 5.9 "Lesson 8: Back Animation in M ATLAB® /Simulink ® " in the INTEC-
RIO Getting Started manual.
In the second step, the Simulink model (
*.mdl
) and the prototype (
*.a2l
and
*.a2l.cod
) are transferred to the PC used for the INCA experiment ("PC (Mea-
surement / Calibration)" in Fig. 9-1).
The way to start and perform the INCA/INCA-EIP experiment is described in the documentation of these tools. Here, only the Simulink back animation is mentioned.
To use the Simulink back animation:
1. In INCA
• Start the INCA experiment.
You can use the INCA instruments as usual.
2. In Simulink
• Open the measurement instruments you have prepared.
• Select
External
from the combo box in the toolbar.
The Connect to target button appears to the left of the combo box.
INTECRIO V4.6 - User’s Guide
ETAS Appendix: The INCA Connector
• Click Connect to target to establish the connection to the experimental target.
The measurement variables are displayed in the instruments.
• Calibrate the parameters as you normally do in
Simulink.
INTECRIO V4.6 - User’s Guide 177
Appendix: The INCA Connector ETAS
178 INTECRIO V4.6 - User’s Guide
ETAS Index
Index
A
Application mode
Application software
ASAM-MCD-2MC generation
ASCET connectivity
automatic re-import of model
Characteristics
Description file
ASCET model
Characteristics during creation
Description file
ASCET modeling
Automapping function
AUTOSAR
–
calibration parameter interface
client-server communication
elements in INTECRIO
interface
inter-runnable variable
Overview
port
Pport
Rport
runnable entity
runtime environment
,
,
sender-receiver communication
software component
,
virtual function bus
AUTOSAR interface
AUTOSAR software component
B
Board types
A/D board
Communication board
D/A board
DIO board
PWM board
Simulation controller board
Build process
Code generation
Compiling
Linker
Parser
Post-processing
Sequence
bypass concept
–
hook-based
,
,
safety
service-based
,
,
,
XCP on CAN
,
XCP on UDP 57
Bypass experiment
Bypass hooks
C cache locking
calibration parameter interface
INTECRIO V4.6 - User’s Guide 179
Index ETAS
180
CAN interface
CAN IO
,
XCP bypass
,
CAN IO
,
client-server communication
Configuration of the operating system
OS configuration
Connection
Dynamic
,
,
Modules
Rules
static
Cooperative scheduling
Crossbar
D
Daisychain
,
Documentor
Dynamic connection
,
,
E
Environment system
,
Working in the project configurator
ES1000 memory pages
ES1000 configuration
–
Board types
import
,
in hardware configurator
manual
XCP on UDP 57
ES1135
XETK
ES4xx
,
ES581
CAN IO
XCP on CAN
ES63x
,
ES900
FETK
XETK
ES900 configuration
–
import
,
in hardware configurator
interface types
Manual configuration
XCP on UDP 57
ES910 memory pages
ES920
ES930
,
ETAS Experiment Environment
–
Calibrating
different targets
Measuring
RTA-TRACE connectivity
Tasks
Ethernet interface
ETK bypass
ETK interface
Experimenting
Bypass experiment
Fullpass experiment
F
FETK 57
,
FETK bypass
FlexRay interface
Fullpass experiment
Function
Working in the project configurator
G
Glossary
–
Abbreviations
–
Terms
–
GT-SUITE model build in INTECRIO
check Simulink model
copy example files
integrate in INTECRIO
multiple GT-SUITE installations
prepare experiment
prepare M ATLAB /Simulink
H
Hardware Configurator
–
Board types (ES1000)
ES1000 configuration
,
ES900 configuration
,
HWX import
interface types (ES900)
interface types (RTPRO-PC)
PC configuration
RTPRO-PC configuration
Supported boards (ES1000)
Supported interfaces (ES900)
Supported interfaces (RTPRO-PC)
XXX to CAN
INTECRIO V4.6 - User’s Guide
ETAS Index
Hardware system
,
,
hook-based bypass
classical
with Distab17
HWX import
,
,
,
HWX1
HWX2
I
IER
Simulink real-time target
INCA connector
–
connect with M ATLAB /Simulink
installation
work with ~
Initialization
Application mode
INTECRIO
AUTOSAR elements
build GT-SUITE model
connect with M ATLAB /Simulink
integrate GT-SUITE model
INTECRIO components
–
ASCET connectivity
Documentor
ES1000 Connectivity
ES900 Connectivity
ETAS Experiment Environment
hardware configurator
INCA connector
M ATLAB /Simulink connectivity
OS configurator
PC connectivity
Project configurator
Project integrator
RTPRO-PC Connectivity
INTECRIO Embedded Coder Real-Time
Target
IER
INTECRIO Real-Time Target
IRT
INTECRIO-ASC
ASCET connectivity
INTECRIO-related tools
INTECRIO-RLINK
INTECRIO-RLINK
interface
Interface types
CAN IO
,
communication interface
,
daisychain
,
Ethernet interface
ETK interface
FlexRay interface
IO interface
,
LIN interface
Simulation controller
System interface
XCP bypass on CAN
,
XCP bypass on UDP 57 inter-runnable variable
Interrupt service routines
IO interface
,
IRT
Simulink real-time target
ISRs
AnalyzeCapable
configuration procedures
Event Dependencies
set up
L
LIN interface
M
M ATLAB /Simulink connect with INCA connector
connect with INTECRIO
prepare for GT-SUITE model
M ATLAB /Simulink connectivity
automatic re-import of model
Characteristics
Description file
Messages
Modeling hints
–
ASCET
GT-SUITE model
Simulink
User code
Module
Connection
Design
Working in the project configurator
INTECRIO V4.6 - User’s Guide 181
Index ETAS
182
O
Operating system
ERCOSEK
RTA-OSEK
RTA-OSEK for PC
Scheduling
Tasks
OS configuration
automatic
import from ASCET
OS configurator
–
Configurator/generator
Design
OIL interface
OSC
,
OSC
,
Automapping function
import from ASCET
ISRs
Offline mode
Online mode
set up ISRs
P
PC configuration
Platform software
port
AUTOSAR
Pport
Preemptive scheduling
Data consistency
Product liability disclaimer
Project configurator
–
Connections
environment
Functions
Modules
Offline mode
Online mode
Software system
SWC
System projects
Project integrator
–
ASAM-MCD-2MC generation
Build process
R
Resources
Rport
RTA-TRACE connectivity
RTPRO-PC memory pages
XETK
RTPRO-PC configuration
–
import
in Hardware Configurator
interface types
Manual configuration
XCP on UDP 57 runnable entity
runtime environment
,
,
S
Safety advice
technical state
Scheduling
,
cooperative
Data consistency
Dynamic
preemptive
Priorities
static
Tasks
SCOOP
–
Concept
SCOOP-IX
,
–
example
scripting
sender-receiver communication
service-based bypass
OS configuration (SBB V3)
specifics
Signal mapping
Software system
System project
Simulink
Target IER
Target IRT
Simulink model
Characteristics during creation
Description file
Simulink modeling
Supported functions
software component
Software system
,
,
Connection
Functions
Modules
Signal mapping
SWC
Working in the project configurator
INTECRIO V4.6 - User’s Guide
ETAS
SWC
,
,
Working in the project configurator
System interface
System project
,
OS configuration
Signal mapping
Working in the project configurator
T
Task
activated
Event
inactive
Priority
,
,
running
Types
U
User code modeling
V
Validation
,
Verification
,
virtual function bus
virtual prototyping
memory pages
W
Workspace
X
XCP bypass on CAN
,
XCP bypass on UDP 57
XETK 57
,
,
,
XETK bypass
XXX to CAN
INTECRIO V4.6 - User’s Guide
Index
183
advertisement