MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Software System Design
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
1/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design I Inhaltsverzeichnis
Datum: 2008-05-09 Version: 5.0 Status: For review
I
Inhaltsverzeichnis
I
Inhaltsverzeichnis
2
II
Präliminarien
4
1
Software System Design
5
1.1
Terms and Abbreviations
5
1.2 1.2.1 1.2.2 1.2.3 1.3 1.3.1 1.3.2 1.3.3 1.3.3.1 1.3.3.1.1 1.3.3.2 1.3.3.2.1 1.3.3.2.1.1 1.3.3.2.1.2 1.3.3.2.2 1.3.3.2.3 1.3.3.2.4 1.3.3.2.5 1.3.3.2.5.1 1.3.3.2.5.1.1 1.3.3.2.5.2 1.3.3.2.5.2.1 1.3.3.2.5.3 1.3.3.2.5.3.1 1.3.3.3 1.3.3.3.1 1.3.3.3.2 1.4 1.4.1 1.4.1.1 1.4.1.2 1.4.1.3 1.4.1.4 1.4.1.5 1.4.1.6 1.4.1.7 1.4.1.8 1.4.1.9 1.4.1.10 1.4.1.11 1.4.1.12 1.4.1.13 1.4.1.14 1.4.1.15 1.4.1.16 1.4.1.16.1 1.4.1.16.2 1.4.1.16.3 1.4.1.16.4 1.4.1.16.5
Project overview MAN Power Train Manager (PTM) Scope Development environment Static Architecture Selection Criteria Physical Structure: Hardware PTM Software Structure Software layers in PTM Layer Middleware Operating System Aspects Partitioning Temporal Partitioning Spatial Partitioning Base Software Local Operating System Load Modules Inter-Application Communication Mechanisms Middleware Details about Middleware System Calls (API) Implementation Memory Layout and MMU Memory Layout from sight of Base Software and applications Use of default values for Middleware signals in PTM Use Cases Implementation Component Description Component CAN Driver Component LIN Driver Component USB Driver Component Digital Input Driver Component Analog Input Driver Component Frequency/PWM Input Driver Component Immobilization (WSP) Driver Component Digital Output Driver Component PWM Output Driver Component Hardware Configuration Table Component External Flash Driver Hardware Pool Component Watchdog Handler Component Exception Handler Component Interrupt Handler Low Side Switch Driver First Level Scheduler Component Clutch Control Travel Sensor Driver (layer 2) Component Oil Level Sensor Driver (layer 2) Second Level Scheduler Component Middleware Manager Component Temperature Sensor Driver (layer 1)
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
6 6 6 6 6 6 6 7 7 8 9 9 9 10 10 10 11 11 11 12 12 12 12 12 17 17 17 17 17 17 17 17 18 18 18 18 18 18 18 18 18 18 18 18 18 19 19 19 19 19 Seite:
2/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ... 1.4.1.16.6 1.4.1.16.7 1.4.1.16.8 1.4.1.16.9 1.4.1.16.10 1.4.1.16.11 1.4.1.16.12 1.4.1.16.13 1.4.1.16.14 1.4.1.16.15 1.4.1.16.15.1 1.4.1.16.15.2 1.4.1.16.15.3 1.4.1.16.16 1.4.1.16.17 1.4.1.16.18 1.4.1.16.19 1.4.1.16.20 1.4.1.16.21 1.4.1.16.22 1.4.1.16.23 1.4.2
Sprache: en
Software System Design I Inhaltsverzeichnis
Datum: 2008-05-09 Version: 5.0 Status: For review
Component Resistor Switch Sensor Driver (layer 1) Component Voltage Supply Driver Component EEPROM Manager Component EEPROM Simulator Frequency/PWM Input Evaluator Component ROM Manager Component XCPonCAN Component XCPonUSB Component High Level Pool Component Diagnosis Manager
19 19 19 19 19 20 20 20 20 20 20 20 20 20 20 20 20 21 21 21 21 21
Component Freeze Driver Component UDS Driver Component Clutch Control Travel Sensor Driver (layer 1) System Manager Component Tilt Sensor Driver Component Exhaust Gas Back Pressure Sensor (AGD) Driver Component Current Solenoid Valve Retarder Driver Oil Level Sensor Driver (layer 1) Component Boot Sector (Boot Program)
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
3/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design II Präliminarien
II
Präliminarien
Projektbeteiligte Firmen
Continental AG [Conti] (Zulieferer) Adresse
Datum: 2008-05-09 Version: 5.0 Status: For review
Name Rolle
Abteilung
Kontakt
Thorsten Grefing [ThG]
SV CV DIV. Sodener Strasse 9 +49 6196 87-2743 ENS PD SW 65824 Schwalbach/TS +49 6196 8779-2743 TPM
[email protected]
MAN Nutzfahrzeuge AG [MAN] Name Rolle
Abteilung
Adresse
Thomas Hörbrand [u22Th] Elektronik Dachauer Strasse 667 Regelungs- 80995 München und Steuerungssysteme (TSE)
Versionsinformation
Datum
Kontakt 089/ 15 80-5812 089 / 15 80-4267
[email protected]
Herausgeber Firma
Version
Status
5.0
For review
Änderung Grund 2008-05-09
Thorsten Grefing Conti
Update document for converting Requirements of the converter and expert meeting 06.11.2007
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
4/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
1
Software System Design
1.1
Terms and Abbreviations
Datum: 2008-05-09 Version: 5.0 Status: For review
Exhaust Gas Back Pressure
Sprache: en
API
Application Programming Interface, the set of documented types, constants, variables and functions
Appl.
Application
BCU
Body Control Unit, a separate ECU from the PTM which is closely related at the system level.
CAN
Controller Area Network, a network protocol defined by Bosch for automotive use.
CRC, CRC32
Cyclic-Redundancy Check, a method of calculating checksums that is highly resilient against errors, based on Galois theory.
ECC1
Extended Conformance Class 1, a subset of the OSEK OS operating system; ECC1 tasks can in contrast to BCC1 tasks also can have the Mode "waiting" or "blocked".
ECU
Electronic Control Unit, jargon for an embedded computer in a automotive vehicle.
EEPROM
Electronically Erasable Programmable Read-Only Memory, a non-volatile memory technology.
FDM
Funktionsdatenmanagement, MAN-specific database of software artifacts.
HLP
High Level Pool
HMI
Human-Machine Interface, the interface the human operator uses (display, knobs, buttons).
HW
Hardware
KL15
Klemme 15, electrical terminal related to engine starting; ignition
KiB, KB
Kibi Byte, 210 = 1024 Bytes (IEC/IEEE unit)
LIN
Local Interconnect Network, a low-cost automotive network. See http://www.lin-subbus.org.
Load Module
absolute object file of a partition
MAN
Maschinenfabrik Augsburg-Nürnberg
MFL
Multifunktions Lenkrad, multi-purpose steering wheel
MMU
Memory-management unit, a processor subsystem which performs virtual to real address translations.
MPC
Microprocessor Controller
MPC5554
Microprocessor employed by PTM.
OIL
OSEK Implementation Language, the configuration language for OSEK OS and OSEK COM.
OS
Operating System
OSEK/VDX
Open systems and the corresponding interfaces for automotive electronics, a standards body for automotive system software, see http://www.osek-vdx.org. Often abbreviated to OSEK.
Partition
Separated software module including code
PTM
Power-Train Manager, the ECU described in this document.
PWM
Pulse-Width Modulation
PowerPC
The name of the processor architecture.
SRS
Software Requirements Specification
SV
Continental (former Siemens VDO, the automotive business unit of Siemens.)
SW
Software
UDS
Unified Diagnostic Services, specified in ISO 14229
USB
Universal Serial Bus, see http://www.usb.org
VSD
Voltage Supply Driver
WSP
Immobilizer (Wegfahrsperre)
XCP
X Calibration Protocoal, defined by ASAM.
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
5/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Exhaust Gas Back Pressure µC/OS-II
realtime operating system for embedded systems
Tabelle 1:
1.2
Project overview This chapter provides an overview for the MAN PTM.
1.2.1
MAN Power Train Manager (PTM) The Power Train Manager is the ECU responsible for power train management in MAN commercial vehicles. It is designed to supplant the Fahrzeugsführungsrechner (FFR), which is a 16-bit based system which is nearing the end of its product life cycle.
1.2.2
Scope The PTM plays a central role in the vehicle's communication network, tying together the engine management unit, the gearbox control unit, the immobilizer, various HMI interfaces in the vehicle's cockpit, the accelerator pedal, the tilt sensor, oil-level, etc. Its main tasks include temperature management motor-related functions gear-related functions engine brake management power divider management retarder management diagnosis management The PTM is designed to use the Freescale MPC 5554, which contains a central processing unit supporting the 32-bit Book E PowerPC architecture. MAN intends to provide the majority of application functionality in the system. MAN will assume the role of system integrator and is responsible for the concrete system architecture (i.e., the concrete set of applications/tasks and their scheduling). Additionally, MAN will do the final software integration, although SV has to pre-integrate the software parts delivered by SV. The PTM architecture provides an operating system that utilizes memory protection, to hinder software faults from propagating from one application to other applications or to the OS. It provides a set of input/output drivers that facilitate access to hardware resources such as pins or controller area network (CAN) communication networks. It provides a Middleware to facilitate communication between the drivers and the applications. Finally, it provides various high-level services, such as diagnostic protocols, and persistent storage, to applications. It is also a design requirement for the system to support modular software updates and modular upgrades/extensions of PTM software-related functionality in the field. The unit of upgrade is a partition, as detailed below.
1.2.3
Development environment
1.3
Static Architecture The PTM is not a turnkey product. Application functionality is provided purely by the customer and third-party suppliers, not by SV.
1.3.1
Selection Criteria The architecture has been developed in close conjunction with the customer, in accordance with the customer's wishes and the initial architecture defined in the project acquisition stage.
1.3.2
Physical Structure: Hardware PTM The figure shows the outside connection of PTM, thus defining the hardware drivers that have to be available. The figure additionally shows the lines and busses that are used by PTM in the vehicle. Frequency Inputs in this figure also include PWM Inputs.
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
6/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Abbildung 1:
1.3.3
Software Structure Components that MAN is responsible for are not further described in this document.
1.3.3.1
Software layers in PTM The following layers can be distinguished: Boot Software, Base Software, Applications. Boot Software: This is the software entry point for PTM. It is also used for loading new software. Base Software includes several parts: Middleware: This is a signal database that is used as the main communication layer. Applications communicate with other applications and with lower layers via the Middleware. The Middleware provides a uniform signal-based interface to applications. Middleware can be accessed via Shared Memory or via System-Call Interface. System-Call Interface: This is the membrane that separates applications (residing in user-space partitions) from the Base Software. High-Level Driver: The system provides various high-level services such as EEPROM manager, diagnosis etc. Low-Level Driver: Low-Level Drivers are responsible for interfacing with the PTM hardware. In general, peripheral inputs and outputs are communicated via the Middleware. However, asynchronous control operations are initiated directly, utilizing the system-call interface. The operating system is the first level scheduler. It is realized with using mC/OS-II. It provides objects such as tasks, resources, alarms to applications. The operating system provides an OSEK interface to applications. Base Software can deal with everything which is part of PTM Hardware. Base Software is not able to interpret the signals it delivers from/to the PTM Hardware. This interpretation must be done by other instances, e.g. by applications. This is the reason for separating some modules into two different layers (layer 1 and layer 2). Applications: These implement the high-level functionality of the PTM. MAN is responsible for design and implementation of applications. Applications use the Middleware signals and/or the additional services (e.g., for EEPROM access). Applications run with user privileges, this means not all instructions can be executed; they cannot corrupt the integrity of the entire system.
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
7/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Abbildung 2: This figures shows the overview of the system. Remarks: Areas with points represent data. Modules of applications (e.g. Clutch Control Driver (layer 2)) are just exemplarily shown in application 1. 1.3.3.1.1
Layer Middleware
This is the main layer the applications communicate through. Middleware wraps the Base Software in the PTM system and delivers a uniform signal based access for the applications. Applications have to ensure that all signals in Middleware, that can be written by applications, are plausible. This means, Base Software does not need to check plausibility of the signals of Middleware (e.g. Is value of Digital Output different from {0, 1}? Are values of PWM Output (frequency and pulse duty factor) valid?) This concept leads to reducing runtime, wrong values will lead to wrong status calculations of Base Software, unwanted behaviour of the actuators connected to PTM.
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
8/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Middleware data for CAN-communication are configurable by MAN before compile time. Since Base Software has to copy input data from hardware to Middleware respectively output data from Middleware to hardware, runtime of Base Software varies on the configuration of CANcommunication. 1.3.3.2
Operating System Aspects A primary aspect in which the PTM differs from previous designs is in the sophistication of its operating system. The following sections describe the design of the operating system and Middleware layers.
1.3.3.2.1
Partitioning
To prevent software faults from propagating, the system is split into separate partitions. Partitioning is an off-line process, done at system build time. No changes to the partitioning schema are possible at run-time. Partitioning means spatial partitioning and temporal partitioning. Each partition has a spatial component and a temporal component. Boot Sector 1 (including Boot-Init), Boot Sector 2, Base Software and each application are separate partitions. The number of application partitions is 3. 1.3.3.2.1.1
Temporal Partitioning
Temporal partitioning means that the processor resource is divided amongst Base Software and the applications according to a fixed schedule. The schedule is characterized by a fixed period in wall-clock time (so-called scheduling period, 10 ms), and a list of (partition, time slice) tuples. Each such tuple is called a phase. The time slice component of the phases must sum to less than the period of the schedule. The schedule period consists of the phases in list order, followed by unallocated time. The processor executes the application's code in those phases that are allocated to its partition. This defines the 1st level scheduler (global operating system). The 1st level scheduler is realized with the operating system µC/OS-II. Time scaling: Each Phase should not use more than 70% of it, because times for interrupts have to be considered. The unit of the times is 500µs. This figure shows an example first level schedule.
Abbildung 3: Annotations: "System Phase" is the phase of Base Software. Phases 1,2,3 are the phases of applications. Each Phase can content unallocated time. Unallocated time of Base Software can be used for less prior Base Software-Background-Activities. Unallocated time of applications
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
9/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
(phase1, ...) can’t be used for less prior Base Software-Background-Activities. Base Software does not see what application is doing. There is no context switch in that case. Runtime of System Phase consists of 2 major parts: Part 1 is a fix part. It is responsible for non-configurable treating of input and output ports, the operating system, etc. Part 2 is a variable part which is dependent on the configuration of CAN-communication done by MAN. CAN-communication data of Middleware (they are defined in Base Software) are configured before compile time. This leads to a variable amount of Middleware-CAN-data which have to transfered by Base Software (System Phase) from/to Middleware to/from hardware by Base Software. 1.3.3.2.1.2
Spatial Partitioning
A partition is characterized by read-only and read/write memory segments. Spatial partitioning means that applications reside in different memory areas that are protected from each other. In particular, code executing in one partition should not modify memory of a different partition in an uncontrolled fashion, even by indirect means. Exception: Parts of Middleware reside in Shared Memory, this means applications can modify a different partition in an uncontrolled fashion. A memory segment is characterized by a length in bytes and a starting address. An application may execute and read from its read-only segment, and modify its read/write segment. Applications do not in general have access to controller registers. Memory Layout shows details about the spatial partioning. 1.3.3.2.2
Base Software
The Base Software can access controller registers. Interrupts are handled in the Base Software, by invocation of interrupt service routines. Although interrupt service routines execute in the address context of the Base Software, they are serviced as soon as possible. In particular, they can interrupt execution of an application partition. The reason for this is that HW controllers, in particular communication controllers for CAN and LIN, do not in general have enough internal buffering resources to allow deferment of their service requests until the next phase boundary. The time used by these interrupt service routines does not extend the current phase. In effect, the time used by the interrupt service routines is subtracted from the time available to the application. This is so that the system period does not vary. Remark: MAN must take care to provide sufficient extra time in each phase to account for processing of interrupt service routines. 1.3.3.2.3
Local Operating System
Each application partition has a local operating system that implements a subset of the OSEKVDX OS standard. Each local operating system implements its own scheduling. The scheduler used within a partition is the 2nd level scheduler. No cooperation is required between the first and second-level scheduler. At phase boundaries, the first-level scheduler simply switches from one local operating system to the next.
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
10/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Abbildung 4: Each application partition supports multiple ECC1 tasks (in the OSEK OS sense) with associated priorities. Each application partition is configured by a separate OIL file. 1.3.3.2.4
Load Modules
A load module is an absolute object file of a partition. Boot Sector 1 (including Boot-Init), Boot Sector 2, Base Software and each application have to consist of an absolute object file. Each Load Module can be flashed on its own. If a Load Module is to be loaded, its maximal memory area has to be erased. Boot Sector 1 cannot flash Boot Sector 1 itself. Service Memory and the 2 EEPROM-blocks in Flash are load modules, too. The MAN software distribution environment is geared to use Intel Hexadecimal Object File Format (Intel Hex) as absolute object file. Therefore, software must be distributed in Intel Hex format. 1.3.3.2.5
Inter-Application Communication Mechanisms
The PTM architecture defines two mechanisms for inter-application communication: a Middleware and an extensible set of system calls. The Middleware allows inter-application communication. It can also be used for intra-application communication. The extensible set of system calls allows invocation of services in the Base Software. 1.3.3.2.5.1
Middleware
The applications may communicate amongst themselves as well as with drivers located in the Base Software using the Middleware. The Middleware is a database that contains signals (read/write-data that are not stored after shut-down), Calibration Data (read-only data that are
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
11/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
stored after shut-down as EEPROM-Parameter), Operational Data (read/write data that are stored after shut-down as EEPROM-Parameter). A comptatiblity check concerning the Middleware has to be done during start-up (Do Middleware files Base SW is generated with match with Middleware applications are generated with and match with Middleware EEPROM contains?). 1.3.3.2.5.1.1
Details about Middleware
There are 2 possibilities how applications can access Middleware signals: Access via application programming interface to Base Software (System Calls), Access via Shared Memory. Accessing Middeware signals via application programming interface to Base Software will be refered to in the successing items and is the safest why of accessing Middleware signals. Reading all signals and writing all signals with each one System Call is atomic and can not be interrupted. 1.3.3.2.5.2
System Calls (API)
System Calls have a certain run-time, because there is a overhead to do (context switch from so-called User-Mode to so-called Supervisor-Mode, ...). A System Call has the run-time of several µs. This has to be considered by applications. 1.3.3.2.5.2.1
Implementation
A system call is implemented by invoking the machine op-code designed for this purpose. In the PTM architecture, system calls should and do not block and should and do not wait for some event. For realising the System Call mechanism the following files are needed: mMDW_SysCallIfc.c, mMDW_SysCallIfc_i.h, mMDW_SysCallIfc_e.h. mMDW_SysCallIfc.c: This file contents the implementation of each System Call, which initializes System Call specific user data field and calls the unique System Call, implementation of the unique System Call which calls the "sc" (System Call opcode of MPC5554) with using the "USPRG0". This file includes mMDW_SysCallIfc_i.h and mMDW_SysCallIfc_e.h. The object of this file is here called mMDW_SysCallIfc.obj. mMDW_SysCallIfc_i.h: This file contents definition of indizes of all System Calls, definition of all System Call specific user data fields. definition of a structure (it includes indizes of System Calls, error field, pointer to System Call specific user data field). This definition is unique for all System Calls. mMDW_SysCallIfc_e.h: This file contents prototypes of System Calls, return values of System Calls, definition of the version of System Call Interface. If extensions are done the version number is arized. Applications need the library mMDW_SysCallIfc.obj and mMDW_SysCallIfc_e.h to be built. Base Software needs mMDW_SysCallIfc_i.h and mMDW_SysCallIfc_e.h to be built. All files are implemented by SV. System Call Interface is extensible. 1.3.3.2.5.3
Memory Layout and MMU
1.3.3.2.5.3.1
Memory Layout from sight of Base Software and applications
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
12/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Abbildung 5:
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
13/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Abbildung 6:
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
14/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Abbildung 7:
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
15/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Abbildung 8:
Abbildung 9: Annotations: "P" in the table means "Permission". "NC" in the table means "not cached". All other entries are cached. Base SW has read/write access to whole RAM area. This is used for Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
16/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
saving TLBs and needed for reading/writing application variables via XCP while debugging. Base SW has access execute/read/write to whole FLASH area. This is used for saving TLBs. Read access is needed for being able to make CRC32 checks during System Phase. Boot Sector 2 is optionally available. 1.3.3.3
Use of default values for Middleware signals in PTM An important point for MAN and for SV is the ability to disassociate "real" input/outputs from the values held in the Middleware. This functionality should be available to all input and output uniformly. Goal: For test and debug purposes the developer/tester must be able to define the values of certain signals independently of the real inputs, either since there are no real input values due to missing hardware or the real signals would disturb the test purposes. Additionally, for actuator tests, it has to be possible to regard only single outputs without being disturbed by other inputs and outputs. This is known as cutting normal signal transmission or "freischneiden".
1.3.3.3.1
Use Cases
Application tests: XCP sets up application input values and checks output values. Input/Output tests via XCP: XCP sets up value output, external monitoring validates proper operation. External stimulus applied to HW inputs, XCP validates proper operation. Actuator Tests Tests in the field (e.g., vehicle maintenance/service) 1.3.3.3.2
Implementation
For each input signal group of the Middleware (this means raw value, average value, by using characteristic curve calculated value, status value, etc. of one signal), a boolean variable exists. This boolean variable decides, if Low-Level-Driver will write hardware information to according Middleware Signals or not. So input signals can be changed by diagnosis tools (e.g. via XCP) by setting the respective value to the boolean variable. Boolean variables as well as input variables can be set via diagnosis tools (i.e. via XCP). 0 = Normal Signal Transmission, Writing to Middleware enabled (Default). 1 = Normal Signal Transmission cut, Writing to Middleware disabled. For each output signal of the Middleware, a primary and a secondary (also called Shadow-) variable exist. For each output signal group (this means value to be written, status value, etc. of one signal), a boolean variable exists. This boolean variable decides, if primary or secondary (also called Shadow-) variable are used by Low-Level-Driver for writing to hardware and writing status back. So applications can do their usual job whereas test variables can be written to hardware by setting the respective value to the boolean variable. Boolean variables as well as output variables can be set via diagnosis tools (e.g. via XCP). Definition of boolean variables: 0 = Normal Signal Transmission, Reading from primary variables in Middleware enabled (Default). 1 = Normal Signal Transmission cut, Reading from secondary (also called Shadow-) variables in Middleware enabled.
1.4
Component Description
1.4.1
Component CAN Driver CAN Driver contents the functionallity treating CAN communication, such as Low Level CanDriver, CANbedded stack , J1939 stack, gateway functionallity.
1.4.1.1
Component LIN Driver LIN Driver reads and writes messages between the different nodes connected to the LIN bus.
1.4.1.2
Component USB Driver USB-Driver reads and writes USB messages.
1.4.1.3
Component Digital Input Driver Digital Input Driver reads digital input values from processor pins. This leads to raw value, average value and status value the driver delivers to Middleware.
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
17/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ... 1.4.1.4
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Component Analog Input Driver Analog Input Driver reads analog input values from processor pins. This leads to raw value, average value and status value the driver delivers to Middleware.
1.4.1.5
Component Frequency/PWM Input Driver Frequency/PWM Input Driver reads frequency/PWM input values from processor pins. This leads to raw value, average value and status value the driver delivers to Middleware.
1.4.1.6
Component Immobilization (WSP) Driver Immobilization (WSP) Driver reads immobilizer input value from processor pins. This leads to transponder code, dongle code and status signla the driver delivers to Middleware.
1.4.1.7
Component Digital Output Driver Digital Output Driver writes digital output values to processor pins. Values of digital outputs are derived from Middleware signals respectively in case of saving driver from High Level Pool Digital Output Evaluator.
1.4.1.8
Component PWM Output Driver PWM Output Driver writes PWM output values to processor pins. Values of PWM outputs are derived from Middleware signals respectively in case of saving driver from High Level Pool PWM Output Evaluator.
1.4.1.9
Component Hardware Configuration Table Hardware Configuration Table is a central point to hold hardware-specifica; hardware-specifica are not hold in multiple modules. Hardware Configuration Table reads Hardware-ID, this is a fix information on PTM. Hardware-ID leads to identifying the HW variant. There is one Variant Hardware Configuration Table including information if a connector pin of HW is available or not for each HW variant. Hardware-ID leads to identifying the HW type.There is one Type Hardware Configuration Table including information if information for all HW variants changed (e.g. processor clock is changed, nevertheless all the variants are supported). Hardware Configuration Table module checks if Base Software matches with hardware variant and hardware type. Hardware Configuration Table initializes MMU.
1.4.1.10
Component External Flash Driver External Flash Driver is needed to erase/write the external flash device. It is used by EEPROM Simulator.
1.4.1.11
Hardware Pool Hardware Pool deals miscellaneous hardware functionallity: RAM-Test, Checksum test, CRC32 test, Hardware Test, Common register initialization.
1.4.1.12
Component Watchdog Handler Watchdog Handler realizes functionallities for triggering Watchdog and testing Watchdog.
1.4.1.13
Component Exception Handler Exception Handler offers exception handler routines for each exception. If an exception occured, debug information is stored in a debug field with information of the essential data when the exception occured.
1.4.1.14
Component Interrupt Handler The Interrupt Handler manages the enabling/disabling and priorities of the interrupts.
1.4.1.15
Low Side Switch Driver Low Side Switch Driver switches ground signals of sensor inputs, calculates status of ground signals of sensor inputs and is responsible for mapping clock for clocked digital inputs.
1.4.1.16 Sprache: en
First Level Scheduler Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
18/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
First Level Scheduler realizes functionallity of operating system, Stack-Test, Task Logging and System Calls. 1.4.1.16.1
Component Clutch Control Travel Sensor Driver (layer 2)
Clutch Control Travel Sensor Driver (layer 2) calculates an absolute value of the clutch control travel using values provided in Middleware. 1.4.1.16.2
Component Oil Level Sensor Driver (layer 2)
Oil Level Sensor Driver (layer 2) calculates an immersion depth of the oil sensor using values provided in Middleware. 1.4.1.16.3
Second Level Scheduler
Second Level Scheduler offers OSEK interface to the applications. The application is configurable with the OIL-file. Alarms caused by the System-Tick lead to activating the according tasks of application. 1.4.1.16.4
Component Middleware Manager
Middleware Manager contents default values for Middleware signals, Calibration Data and Operational Data. It realizes transfering Middleware signals from Middleware to output drivers respectively transfering Middleware signals into Middleware from input drivers. For both CAN and LIN, Middleware Manager puts Middleware signals into messages respectively it puts messages into Middleware signals with regarding rules and calculating statuses. Middleware Manager realizes cutting normal signal transmission. 1.4.1.16.5
Component Temperature Sensor Driver (layer 1)
Temperature Sensor Driver (layer 1) calculates resistances and the status, using average voltage and the status calculated by Analog Input Driver. 1.4.1.16.6
Component Resistor Switch Sensor Driver (layer 1)
Resistor Switch Sensor Driver (layer 1) calculates resistances and the status, using average voltage and the status calculated by Analog Input Driver. 1.4.1.16.7
Component Voltage Supply Driver
Voltage Supply Driver is split into 3 parts, the Voltage Calculator, the Sensor Supply Evaluator and the KL15 Evaluator. Voltage Calculator does: calculating normed voltages and the status, using average voltage and the status calculated by Analog Input Driver; evaluating "KL30_HSS" which may lead to switching of High Side Switches; evaluating processor overvoltage which may lead to setting all analog input values to not plausible. Sensor Supply Evaluator does: calculating status for sensor supplies and if necessary switching them off. KL15-dependinginputs Evaluator does: evaluating KL15 and setting status for KL15-depending inputs accordingly. 1.4.1.16.8
Component EEPROM Manager
EEPROM Manager cares for offering the correct data from non-volatile memory after Start-Up and saving them into non-volatile memory during shut-down. There are multiple kinds of Data: Calibration Data (read-only for applications) and Operational Data (read/write for applications). 1.4.1.16.9
Component EEPROM Simulator
EEPROM Simulator offers services to the EEPROM Manager. 2 Pages concept is realized (this means EEPROM data set is held twice in RAM: one EEPROM data set in such-called original page and one EEPROM data set in such-called working page; additionally that EEPROM data set is held in non-volatile memory). EEPROM Simulator realizes writing and reading correct data from and into non-volatile memory and original page. 1.4.1.16.10
Frequency/PWM Input Evaluator
Frequency/PWM Input Evaluator calculates status for the Frequency/PWM inputs, using frequency as well as corresponding voltage and the status calculated by Frequency Input Driver and Analog Input Driver. Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
19/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ... 1.4.1.16.11
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Component ROM Manager
ROM Manager module handles data similar to EEPROM data with the difference, that this data must not be stored in EEPROM. Data treated by ROM Manager resides in non-volatile-memory. ROM Manager realizes two different issues: It ensures to have non-volatile data that may only be written once (e.g. production data). It offers data like EEPROM data to Booter (Booter does not work with EEPROM Manager and EEPROM Simulator in order to be able to have a small Booter). Data handled by ROM Manager are visible for the ECU software as EEPROM calibration parameters. 1.4.1.16.12
Component XCPonCAN
XCPonCAN Driver offers XCP services of the PTM using CAN. 1.4.1.16.13
Component XCPonUSB
XCPonUSB Driver offers XCP services of the PTM using USB. 1.4.1.16.14
Component High Level Pool
High Level Pool is split into 3 parts, the Digital Output Evaluator, the PWM Output Evaluator and the Digital Input Adjuster. Digital Output Evaluator calculates status for the digital outputs and if necessary gives order to Digital Output Driver to switch the outputs off or on. PWM Output Evaluator calculates status for the digital outputs and if necessary gives order to PWM Output Driver to switch the outputs off or on Digital Input Adjuster adjusts PWM-signal that is responsible for measuring the clocked digital inputs, considering value of KL30. 1.4.1.16.15
Component Diagnosis Manager
The major task of the Diagnosis Manager is to debounce and to store faults as well as handle warnings and send them via DM1 or DM4 messages on the CAN. 1.4.1.16.15.1
The Diagnosis Manager consists of three different memories. These are: floating memory, confirmed memory, mirror memory. 1.4.1.16.15.2
The floating memory is used for a first debouncing of errors. After debouncing is expired the errors will move from the floating to the confirmed memory. The errors will remain, in active or in inactive state in the confirmed memory. The third memory is the mirror memory. This memory ensures having a historical view. 1.4.1.16.15.3
Configuration of the Diagnosis Manager can be done via an EOL-table. Here it is possible to configure each SPN separately. 1.4.1.16.16
Component Freeze Driver
Freeze Driver cares for having the latest valid sensor signals if the corresponding switchable supply or switchable ground are switched off, which leads to have influence to the sensor signal. 1.4.1.16.17
Component UDS Driver
UDS Driver offers UDS services of the PTM. 1.4.1.16.18
Component Clutch Control Travel Sensor Driver (layer 1)
Clutch Control Travel Sensor Driver (layer 1) calculates a measured voltage and measured time as well as a status and delivers calculated values to Middleware. 1.4.1.16.19
System Manager
System Manager is the main instance of the Base Software. It rules Start-up, System-Phase and Shut-Down. System Manager's Start-up calls the constructors of all drivers. System Manager's System Phase calls the handlers of all drivers. It realizes a such-called System-State Model (defining which system status is active, e.g. Start-Up, Normal-Mode, Shut-Down, Safe
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
20/21
MAN Nutzfahrzeuge AG Autor: Thorsten Grefing Abtl.: SV CV DIV. ...
Software System Design 1 Software System Design
Datum: 2008-05-09 Version: 5.0 Status: For review
Mode, ...). It offers information if common errors occured during Start-up, System-Phase and Shut-Down. It offers System Call Interface. 1.4.1.16.20
Component Tilt Sensor Driver
Tilt Sensor Driver calculates tilt in x- and y-direction and the status, using average voltage and the status calculated by Analog Input Driver. 1.4.1.16.21
Component Exhaust Gas Back Pressure Sensor (AGD) Driver
Exhaust Gas Back Pressure Sensor (AGD) calculates status for the AGD sensor and if necessary switches the sensor off and on again. 1.4.1.16.22
Component Current Solenoid Valve Retarder Driver
Current Solenoid Valve Retarder Driver calculates a current, using average voltage and the status calculated by Analog Input Driver. 1.4.1.16.23
Oil Level Sensor Driver (layer 1)
Oil Level Sensor Driver (layer 1) calculates a set of voltages at the beginning and at the end of oil measurement as well as a status. These voltages are measured after having embossed a current into the oil level sensor. The driver delivers the set of calculated data to Middleware.
1.4.2
Component Boot Sector (Boot Program) 2 Booters are provided. Booter 1 must be available whereas Booter 2 may be available. If Booter 2 is valid available, Booter 2 will excecute Booter functionallity. Booter is the instance that is jumped to during start-up (to check if Base Software is valid available and jump into if yes) as well for loading Load Modules.
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfältigung und Weitergabe an Dritte ist untersagt.
"C:\Daten\01_Projekte\01_PTM\SVN-mit-CONTI\03_SVDO\02_Software\06_Dokumentation\SSD\SSD_MAN_PTM.xml"
Seite:
21/21
