SSD Man PTM

MAN Nutzfahrzeuge AG
Autor: Thorsten Grefing

Abtl.: SV CV DIV. ...
Software System Design
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

I Inhaltsverzeichnis
Datum: 2008-05-09
Version: 5.0
Status: For review
Inhaltsverzeichnis
Inhaltsverzeichnis
II
Prliminarien
1.1
Terms and Abbreviations
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
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
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

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
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)
Seite:
3/21

II Prliminarien
II
Prliminarien
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
Thorsten.Grefing@continental-corporation.com
MAN Nutzfahrzeuge AG [MAN]

Name
Rolle
Abteilung
Adresse
Thomas Hrbrand [u22Th] Elektronik

Dachauer Strasse 667
Regelungs- 80995 Mnchen
und
Steuerungssysteme (TSE)
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
Update document for converting

Requirements of the converter and expert meeting 06.11.2007
Sprache: en
Seite:
4/21

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-Nrnberg
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.
Seite:
5/21

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 Fahrzeugsfhrungsrechner (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
Seite:
6/21

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
Seite:
7/21

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
Seite:
8/21

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 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
Seite:
9/21

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
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
Seite:
10/21

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
Seite:
11/21

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
Seite:
12/21

Datum: 2008-05-09
Version: 5.0
Status: For review
Abbildung 5:
Sprache: en
Seite:
13/21

Datum: 2008-05-09
Version: 5.0
Status: For review
Abbildung 6:
Sprache: en
Seite:
14/21

Datum: 2008-05-09
Version: 5.0
Status: For review
Abbildung 7:
Sprache: en
Seite:
15/21

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
Seite:
16/21

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
Seite:
17/21
1.4.1.4

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

Seite:
18/21

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
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
Seite:
19/21
1.4.1.16.11

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
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
Seite:
20/21

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
Seite:
21/21

SSD Man PTM

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SSD Man PTM

Hochgeladen von

Copyright:

Verfügbare Formate

MAN Nutzfahrzeuge AG

Autor: Thorsten Grefing

Software System Design

Software System Design

Software System Design

Software System Design

Terms and Abbreviations

Software System Design

Component Resistor Switch Sensor Driver (layer 1)

Component Freeze Driver

Software System Design

Continental AG [Conti] (Zulieferer)

Thorsten Grefing [ThG]

SV CV DIV. Sodener Strasse 9

MAN Nutzfahrzeuge AG [MAN]

Thomas Hrbrand [u22Th] Elektronik

Update document for converting

Software System Design

Software System Design

Terms and Abbreviations

Exhaust Gas Back Pressure

Cyclic-Redundancy Check, a method of calculating checksums that is highly resilient against

Electronic Control Unit, jargon for an embedded computer in a automotive vehicle.

Electronically Erasable Programmable Read-Only Memory, a non-volatile memory technology.

Funktionsdatenmanagement, MAN-specific database of software artifacts.

High Level Pool

Klemme 15, electrical terminal related to engine starting; ignition

Kibi Byte, 210 = 1024 Bytes (IEC/IEEE unit)

Local Interconnect Network, a low-cost automotive network. See http://www.lin-subbus.org.

absolute object file of a partition

Multifunktions Lenkrad, multi-purpose steering wheel

Memory-management unit, a processor subsystem which performs virtual to real address

Microprocessor employed by PTM.

Separated software module including code

Power-Train Manager, the ECU described in this document.

The name of the processor architecture.

Software Requirements Specification

Continental (former Siemens VDO, the automotive business unit of Siemens.)

Unified Diagnostic Services, specified in ISO 14229

Universal Serial Bus, see http://www.usb.org

Voltage Supply Driver

X Calibration Protocoal, defined by ASAM.

Software System Design

Exhaust Gas Back Pressure

realtime operating system for embedded systems

MAN Power Train Manager (PTM)

Physical Structure: Hardware PTM

Software System Design

Software layers in PTM

Software System Design

Software System Design

Operating System Aspects

Software System Design

A partition is characterized by read-only and read/write memory segments.

The Base Software can access controller registers.

Local Operating System

Software System Design

Inter-Application Communication Mechanisms

Software System Design

Details about Middleware

System Calls (API)

Memory Layout and MMU

Memory Layout from sight of Base Software and applications