Glossary

ASAM

Standardization committee in the automotive industry for data models, interfaces and syntax specifications. Founded in 1991 as an initiative in the German automotive industry. Today, ASAM is a global committee with over 100 member companies worldwide.

Autosar

AUTomotive Open System Architecture (www.autosar.org). Evolving standard of the automotive industry to define the implementation of embedded systems in vehicles including communication mechanisms. An important part is the standardization of C-functions and macros to communicate between software components. AUTOSAR is targeted to build on top of the real-time operating system OSEK. The use of the AUTOSAR standard requires AUTOSAR membership.

CAN ECU Interface

The CAN ECU interface is connected to a CAN port on the ECU. Most transportation ECUs use a variant of the CAN bus for vehicle ECU connection. The CAN ECU interface is dependent on an ECU resident calibration service routine to manipulate the calibration memory. The host PC calibration application communicates to the ECU and service routine via a special protocol called CCP or CAN Calibration Protocol. There is also a new variant of this protocol with functional extensions called XCP.

CAN Network Data

The ECU interface is primarily used to change the calibration variables. As mentioned above it is also a data collection tool. During the calibration process, the engineer may want to collect and correlate data from the ECU. An example of ECU data would be RPM, spark advance, or injection pulse width.

Code Export

Process during which a model and its solver is transferred into exported code (most of the time, into C Source Code).

Code Generation

In computer science, code generation is the process by which a compiler's code generator converts some intermediate representation of source code into a form (e.g., machine code) that can be readily executed by a machine.

Compiler

Computer software that translates (compiles) source code written in a high-level language (e.g., C++) into a set of machine-language instructions that can be understood by a digital computer's CPU. Compilers are very large programs, with error-checking and other abilities. Some compilers translate high-level language into an intermediate assembly language, which is then translated (assembled) into machine code by an assembly program or assembler. Other compilers generate machine language directly.

Controller

Part of a system which monitors and reacts to changes in the systems state. In SiL simulation, it refers to the (embedded) control software that executes with simulated hardware (plant).

ECU (Electronic Control Unit)

Embedded system that controls one or more electrical subsystems in a vehicle, for instance. In a car, examples for ECU are: Engine Control Unit (ECU), Transmission Control Unit (TCU), Telephone Control Unit (TCU), Man Machine Interface (MMI), Door Control unit, Seat Control Unit, Climate Control Unit.

Embedded Operating System

An embedded operating system is an operating system for embedded computer systems. These operating systems are designed to be very compact and efficient, forsaking many functions that non-embedded computer operating systems provide, and which may not be used by the specialized applications they run. They are also frequently real-time operating systems.

Embedded system

An embedded system is a computer system designed to perform one or a few dedicated functions often with real-time computing constraints. It is embedded as part of a complete device often including hardware and mechanical parts. By contrast, a general-purpose computer, such as a personal computer (PC), is designed to be flexible and to meet a wide range of end-user needs. Embedded systems control many devices in common use today.

Exported Code

Code (most of the time, C Source Code) that can be used for Hardware-in-the-Loop Simulation, Rapid Control Prototyping, Model Integration into other simulation programs (typically Simulink via a S-function) or even accelerated simulation runs.

Fault Insertion

The majority of Hardware-In-the-Loop testing time is used to test the fault detection capability of the ECU. Modern automotive ECUs dedicate half of their memory to this task. Key to testing is fault insertion such as wire breaks, shorts to power, shorts to ground, or sensor/actuator failures. Simulating these events is a relay matrix between the Hardware-In-the-Loop and the ECU.

FlexRay Protocol

Field bus developed by the FlexRay consortium for control functions in the automotive industry. Through its high transfer rates and a fault-tolerant design it is particularly suitable for the use in active safety and powertrain systems.

HiL (Hardware-in-the-Loop)

Mixed software/hardware environment dedicated to function testing during which previously implemented control strategies will be tested and validated on the real ECU. This phase allows to perform regulation, security and failure tests without any risk and to test the interaction between several ECU/TCUs for better robustness/quality.

Host PC

A host PC is used to provide a GUI to the user, to run test automation applications, to control Hardware-In-the-Loop system components such as fault insertion switching, and to provide a diagnostic link to the ECU, to develop/change models and tests, and to collect, store, and report test results. The link between the host and the real-time system is typically Ethernet. Other methods such as proprietary high-speed serial or parallel bus are also used.

Legacy Code

Legacy code is source code that relates to a no-longer supported or manufactured operating system or other computer technology. The term can also mean code inserted into modern software for the purpose of maintaining an older or previously supported feature. It may also be in the form of supporting older file formats that may have been encoding in non-ASCII characters. In practice, most source code has some dependency on the platform for which it is designed unless a platform-independent programming language was used. When a platform is upgraded or superseded, the code may no longer work without changes, and becomes legacy code. A large part of the task of a software engineer is to continually alter code to prevent this. While the term usually refers to source code, it can also apply to executable code that no longer runs on a later version of a system, or requires a compatibility layer to do so.

Linker

A linker is a part of a compiler program that combines a number of archive files, relocates their data and ties up symbol references. The linking process is usually the last step in compiling program.

Microcontroller

A microcontroller (sometimes abbreviated µC, uC or MCU) is a small computer on a single integrated circuit containing a processor core, memory, and programmable input/output peripherals. Program memory in the form of NOR flash or OTP ROM is also often included on chip, as well as a typically small amount of RAM. Microcontrollers are designed for embedded applications, in contrast to the microprocessors used in personal computers or other general purpose applications.

MiL (Model-in-the-Loop)

Software environment used at the function design stage to allow the design of control strategies with help of a representative (accurate) model of the system and its actuators. At this level, virtual models are used for the control (typically in Simulink) and the system (typically in Simcenter Amesim ) and the co-simulation is possible. The objectives of this phase are understanding, function specification, investigation on concepts, strategy design.

Model Reduction

For Control Systems, Model Reduction is the process of discarding certain modes of motion while retaining others in the model used by an active control system, in order that the control system can compute control commands with sufficient rapidity.

Object code

The code produced by a compiler from the source code, usually in the form of machine language that a computer can execute directly. It may however be written in assembly language, an intermediate code that is then translated into machine language.

PiL (Processor-in-the-Loop)

Name given to a testing phase during which the software is executed typically on a prototypical hardware board equipped with the (planned) target processor, thus allowing the evaluation of the main possible scenarios. The objective is an early assessment of the concrete resource requirements of the software (timing domain, memory consumption, etc.). PiL is usually considered as a subset of the HiL phase.

Plant Model

The plant model is the engine model, vehicle model, airplane model, etc. that is expected by the ECU. Its complexity level depends on the desired application. For developing ECU control capability against the plant model, higher fidelity may be required than for only testing the diagnostic capability of the ECU. For instance, to develop a new multi-injection fueling strategy for a diesel engine, the plant model should be capable of accumulating and reacting to all of the fuel pulses.

Rapid Control Prototyping (RCP)

Rapid Control Prototyping is a process which lets the engineer quickly test and iterate their control strategies on a real-time computer with real input/output devices. Rapid control prototyping is a variant of Hardware-in-the-Loop (HiL), but is distinct and popular enough to warrant its own name (and acronym). Rapid Control Prototyping differs from HiL in that the control strategy is simulated in real-time and the plant, or system under control, is real.

Real-Time (Hard RT, Soft RT)

The classical conception is that in a hard real-time or immediate real-time system, the completion of an operation after its deadline is considered useless - ultimately, this may cause a critical failure of the complete system. A soft real-time system on the other hand will tolerate such lateness, and may respond with decreased service quality (e.g., omitting frames while displaying a video). Hard real-time systems are used when it is imperative that an event is reacted to within a strict deadline. Such strong guarantees are required of systems for which not reacting in a certain interval of time would cause great loss in some manner, especially damaging the surroundings physically or threatening human lives (although the strict definition is simply that missing the deadline constitutes failure of the system). For example, a car engine control system is a hard real-time system because a delayed signal may cause engine failure or damage. Other examples of hard real-time embedded systems include medical systems such as heart pacemakers and industrial process controllers.

Real-Time Computing

Real-Time computing (RTC), or reactive computing, is the study of hardware and software systems that are subject to a "real-time constraint" i.e., operational deadlines from event to system response. Real-time programs must execute within strict constraints on response time. By contrast, a non-real-time system is one for which there is no deadline, even if fast response or high performance is desired or preferred. The needs of real-time software are often addressed in the context of real-time and synchronous programming languages, which provide frameworks on which to build real-time application software.

Real-Time Operating System (RTOS)

A Real-Time operating system (RTOS) is an operating system (OS) intended to serve real-time application requests. A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes to accept and complete an application's task: the variability is jitter. A hard real-time operating system has less jitter than a soft real-time operating system.

Real-Time Targets and Inputs/Outputs (RTIO)

The majority of Hardware-In-the-Loop systems uses embedded computers to run the models in real-time. The reason for this is to decouple the real-time computing of the Hardware-In-the-Loop system from the host PC. The PC with a MS-Windows operating system is not real-time. There are some Hardware-In-the-Loop vendors that do use PC hardware for the run-time platform and they accomplish this by running a PC real-time operating system (RTOS) like QNX®. The embedded computers, a.k.a. targets communicate with each other and system I/O via a data bus.

ROM Emulator Interface

This interface is chosen for the most difficult ECUs, i.e. the ones with the most calibration memory such as engine control units or transmission control units. The reason is speed. The ROM emulator is physically attached to the bus of the microcontroller on the ECU. The calibration memory is mapped off the ECU and onto the ROM emulator. By virtue of now containing the calibration memory, the ROM emulator device can log and manipulate the variables. Speed in switching parameter sets is achieved by bank switching the calibration memory. Also, the processor is completely unaffected by the calibration tool it doesn't even know it is there.

Sensor Models

This aspect of the Hardware-In-the-Loop system is often overshadowed by the plant model, but it is nonetheless very important. The sensor outputs from a plant model are perfect they are, after all, just variables. Unfortunately, real-world sensors are not perfect. Their greatest imperfection is their non-linearity. ECUs compensate for sensor non-linearity, thus, the imperfect sensor response must be modeled. The typical sensor model is realized as a look-up-table since the response it typically fast compared to the time-constants of the plant. If the dynamic response of the sensor is slow, it can be modeled dynamically. Some Hardware-in-the-Loop systems will dedicate an entire processor to the sensor models, thus decoupling them from the plant model.

SiL (Software-in-the-Loop)

Within a real-time capable environment, SiL denotes a design phase dedicated to implementation of the control strategies (software) defined at the MiL phase, for testing on a plant model including CAN or FlexRay protocol. Tests can be performed within Simcenter Amesimusing the generated C code for the control or an imported Simulink model, or within Simulink by exportingSimcenter Amesim models. These tests are possible in a virtual real-time environment or off-line. The objectives of this phase are the testing of algorithms and logic and a first software validation for enabling the adaptation of the models to real-time computing.

Source Code

Source code is any collection of statements or declarations written in some human-readable computer programing language. Source code is the means most often used by programmers to specify the actions to be performed by a computer. A computer program's source code is the collection of files needed to convert from human-readable form to some kind of computer-executable form. The source code may be converted into an executable file by a compiler, or executed on the fly from the human readable form with the aid of an interpreter.

Test Automation Application

This application may be built-in to the GUI or be a separate application that sits on top of the GUI. This application provides the user with the ability to automate tests. It accomplishes this task by providing the user with a method of authoring a test sequence. The method can be a test script in a language such as Visual Basic® or Python® or it may be symbolic like flowcharts. There is currently no standard language for Hardware-In-the-Loop test automation.

xPC Target

xPC Target is a real-time software environment from Mathworks. Together with x86-based real-time systems, it enables engineers to simulate and test Simulink and Stateflow models at an early-as-possible stage in real-time on the physical hardware under test.