Professional Documents
Culture Documents
Datum: 2008-05-09
Version: 5.0
Status: For review
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfltigung
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. ...
Datum: 2008-05-09
Version: 5.0
Status: For review
Inhaltsverzeichnis
Inhaltsverzeichnis
II
Prliminarien
1.1
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 Vervielfltigung
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
Datum: 2008-05-09
Version: 5.0
Status: For review
19
19
19
19
19
20
20
20
20
20
20
20
20
20
20
20
20
21
21
21
21
21
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfltigung
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. ...
II
Prliminarien
Projektbeteiligte
Firmen
Datum: 2008-05-09
Version: 5.0
Status: For review
Name
Rolle
Abteilung
Kontakt
Abteilung
Adresse
Versionsinformation
Datum
Kontakt
089/ 15 80-5812
089 / 15 80-4267
Thomas.Hoerbrand@man.eu
Herausgeber
Firma
Version
Status
5.0
For review
nderung
Grund
2008-05-09
Thorsten Grefing
Conti
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfltigung
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. ...
1.1
Datum: 2008-05-09
Version: 5.0
Status: For review
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
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
EEPROM
FDM
HLP
HMI
Human-Machine Interface, the interface the human operator uses (display, knobs, buttons).
HW
Hardware
KL15
KiB, KB
LIN
Load Module
MAN
Maschinenfabrik Augsburg-Nrnberg
MFL
MMU
MPC
Microprocessor Controller
MPC5554
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
PTM
PWM
Pulse-Width Modulation
PowerPC
SRS
SV
SW
Software
UDS
USB
VSD
WSP
Immobilizer (Wegfahrsperre)
XCP
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfltigung
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. ...
Datum: 2008-05-09
Version: 5.0
Status: For review
Tabelle 1:
1.2
Project overview
This chapter provides an overview for the MAN PTM.
1.2.1
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
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfltigung
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. ...
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
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfltigung
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. ...
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 Vervielfltigung
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. ...
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
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 500s. 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 Vervielfltigung
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. ...
Datum: 2008-05-09
Version: 5.0
Status: For review
(phase1, ...) cant 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
Base Software
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 Vervielfltigung
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. ...
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
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 Vervielfltigung
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. ...
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
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 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
1.3.3.2.5.3.1
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfltigung
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. ...
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 Vervielfltigung
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. ...
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 Vervielfltigung
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. ...
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 Vervielfltigung
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. ...
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 Vervielfltigung
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. ...
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
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
1.4.1.1
1.4.1.2
1.4.1.3
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfltigung
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
Datum: 2008-05-09
Version: 5.0
Status: For review
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
Hardware Pool
Hardware Pool deals miscellaneous hardware functionallity: RAM-Test, Checksum test, CRC32
test, Hardware Test, Common register initialization.
1.4.1.12
1.4.1.13
1.4.1.14
1.4.1.15
1.4.1.16
Sprache: en
"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. ...
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
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
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 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
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
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
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
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
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
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 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 Vervielfltigung
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
Datum: 2008-05-09
Version: 5.0
Status: For review
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
Component XCPonUSB
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
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
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
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 Vervielfltigung
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. ...
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
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
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
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) 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
Sprache: en
Der Inhalt dieses Dokumentes ist geistiges Eigentum der MAN Nutzfahrzeuge AG. Jegliche Vervielfltigung
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