Sad 10033136 Po10cg

Aptiv Advanced Safety & User Experience
Connectivity & Security
Software Architectural Design (SAD)
10033136 MY2022 Porsche

Smart Actuator Charger Interface Device (SACID)
Document SAD_10033136_PO10CG
Revision 4.2
Status Approved
Date 22-July-2020
Prepared by:
Aravind Vazhathattil
Aptiv Advanced Safety & User Experience
Confidential – Restricted Aptiv information. Do not disclose.
It is not allowed to reproduce this document in any form without specific written permission by Aptiv Advanced Safety & User Experience.
Copyright © 2018 Aptiv Advanced Safety & User Experience. All rights reserved.
Software Architectural Design
10033136 SACID
Review and Approval

The owner of this Software Architectural Design (SAD) is: Aravind Vazhathattil (Software Architect)
This Software Architectural Design (SAD) document shall be reviewed and approved by the following:
Reviewer Title Reviewer Name Approval Date

Technical Manager/Senior Software Architect Jagadish R 16-July-2020
Software Engineering Group Manager Dennis Joseph 16-July-2020
Software Project Manager Dariusz Janicki 22-July-2020
Lead Software Engineer Meet Desai 22-July-2020
Functional Safety Manager Software Adlene Suji George 16-July-2020
System Architect Karol Matys 16-July-2020
Cybersecurity Engineer Bharath Kumar M 16-July-2020
Software Quality Engineer Dhruva MB 16-July-2020
Revision Record
Revision Revision Date Description / Reason for Revision Author
Number Status*
0.1 Draft 21-Mar-2019 First version of the SAD Dennis
0.2 Draft 23-Apr-2019 Updated static Architecture definition, Added Mcu details Aravind V
and dynamic architecture details
0.3 In Review 12-June-2019 Added section Memory Map , IoHwAb, Lin Aravind V
communication, Interrupts, Data consistency Mechanism
0.4 In Review 14-June-2019 Updated the review comments Aravind V
1.0 Approved 14-June-2019 Changed document status to approved and Updated Aravind V
Approval date
1.1 In Review 20 -Sept- 2019 Updated Project Information Aravind V
Updated Static Architecture Description
Updated Microcontroller Resource
Updated Overview
Added Software Block Diagram
Added non-volatile memory handling and UDS
diagnostic
Added VKMS, SOK and SysSup in CDD
Added Software Component Description (AVS, VAS,
PPE l LKPE , VALK , ISO)
Added Safety Mechanism
Added Security Concepts
Added software Update
Updated Task definition
Added Task Mapping
Updated Interrupts
Added Resource Consumption Estimates
Added AUTOSAR Configuration Tools.
1.2 In Review 24-Sept-2019 Updated the review comments Aravind V
2.0 Approved 24-Sept-2019 Changed document status to approved and Updated Aravind V
Approval date
Approved- Revision 4.2 Page 2 of 99

Copyright © 2019 Aptiv Advanced Safety & User Experience Confidential – Restricted Aptiv information. Do not disclose.
10033136 SACID

Number Status*
2.1 Draft 11- December- - Carry over parts (if any) from other projects. Aravind V
2019 - New concepts and technologies
- Added description of Vector CDD modules
TLS,Exi,XMLSec , Cdd_CpuLoadMonitor
- Added description of SWC SFD
- Network dependencies ,and roles
- Added update mechanism of logical blocks
Hardware configuration Area
Bootloader
Application software and QCA firmware
HSM firmware
- Added debug interface mechanism (e g: XCP)
- Added resource usage estimates
- Added Critical functional requirements.
2.2 Draft 17-February-2020 Updated software safety concepts. Aravind V
- Added self test
- Added Data consistency mechanism
- Added safety measure for Communication
- Added Memory partition and protection
- Added Program flow monitoring
- Updated Watch Dog handling
- Updated Error Management
Added Data Flow
Updated Task mapping
- Cycle time
- Added runnable ASIL Level
- Task order
- Task MPU settings
- Runnable MPU settings
ISR
- Assigned OS application
- ASIL Level
Updated Memory map
- Added ROM Memory map
- Added Ram Memory map
- Added Data storage
- Added Data buffer
Updated software Update
- Added interaction between Application and
Bootloader.
Updated Description of Software Components
- Added SWCs CCDC , CDOE , LKAE
2.3 In Review 24-February-2020 Fixed Peer Review Comments (Peer review Id : Aravind V
382642.7193)
Added section 5.7 OS Hook functions
Added section 4.3.7 IDSM
Added section 3.3 Hardware fallback strategy
Added section 4.1.2.4 SW component Responsibilities
Added section 4.3.8 JTAG protection
3.0 Approved 24-February-2020 Changed document status to approved and Updated Aravind V
Approval date
3.1 In Review 18-May-2020 Added failsafe handling in Section 5.1 Aravind V
Removed empty chapter 6

10033136 SACID

Number Status*
3.2 In Review 12-June-2020 Fixed Review comments (Review ID : 403910.5457) Aravind V
Updated ECU State Diagram (Chapter 5.1)
Updated failsafe handling in section 5.1
Added section 4.1.2.3.11.12 , 4.1.2.3.11.13,
4.1.2.3.11.14
4.0 Approved 16-July-2020 Changed document status to approved and Updated Aravind V
Approval date
4.1 In Review 20-July-2020 Corrected improper ending of sentence. Aravind V
Section 3.2
4.2 Approved 22-July-2020 Changed document status to approved and Updated Aravind V
Approval date
*Revision Status of this document can be: Draft, In Review and Approved

10033136 SACID
Table of Contents
1 Scope and Project Information ...................................................................................................................... 7
1.1 Intended Audience ................................................................................................................................ 7
1.2 Project Information ................................................................................................................................ 7
2 Functional Description ................................................................................................................................... 8
2.1 Overview ............................................................................................................................................... 8
2.2 System Hardware Block Diagram ......................................................................................................... 8
2.3 Software Block Diagram ........................................................................................................................ 9
2.4 Variant Information for SACID System ............................................................................................... 10
2.5 Carry-over parts from other Projects ................................................................................................... 10
2.6 New concepts and Technologies ........................................................................................................ 10
3 Micro-controller Resources .......................................................................................................................... 11
3.1 MCU Description ................................................................................................................................. 11
3.2 Microcontroller peripherals .................................................................................................................. 11
3.2.1 PLL .................................................................................................................................................. 12
3.2.2 CAN- FD .......................................................................................................................................... 12
3.2.3 LIN ................................................................................................................................................... 12
3.2.4 ETHERNET ..................................................................................................................................... 13
3.2.5 SPI ................................................................................................................................................... 13
3.2.6 ADC ................................................................................................................................................. 13
3.2.7 Timer Modules (System Timer and GPT) ....................................................................................... 14
3.2.8 PWM ................................................................................................................................................ 14
3.2.9 Digital IOs ........................................................................................................................................ 14
3.2.10 Flash ............................................................................................................................................ 14
3.2.11 RAM ............................................................................................................................................ 15
3.3 Hardware fallback Strategy ................................................................................................................. 15
4 Static Architecture Description ..................................................................................................................... 16
4.1 Architecture Definition ......................................................................................................................... 16
4.1.1 Alternate Architecture Evaluation .................................................................................................... 16
4.1.2 Main software structure ................................................................................................................... 16
4.2 Software Safety Concept .................................................................................................................... 50
4.2.1 Self-Test .......................................................................................................................................... 50
4.2.2 Data Consistency Mechanism ......................................................................................................... 52
4.2.3 Safety measure for Communication ................................................................................................ 52
4.2.4 Memory Partition and Protection ..................................................................................................... 54
4.2.5 Program Flow Monitoring ................................................................................................................ 57
4.2.6 Alive Supervision ............................................................................................................................. 59
4.2.7 Timing Protection ............................................................................................................................ 59
4.2.8 Watchdog ........................................................................................................................................ 60
4.2.9 Error Management .......................................................................................................................... 61
4.3 Security Concepts ............................................................................................................................... 63
4.3.1 Hardware Security Module (HSM) .................................................................................................. 63
4.3.2 Secure Boot..................................................................................................................................... 64
4.3.3 Secured Communication with HCP5 ............................................................................................... 66
4.3.4 Secured PLC communication .......................................................................................................... 67
4.3.5 Vehicle Key Management System .................................................................................................. 68
4.3.6 Security Access to Diagnostic services........................................................................................... 69
4.3.7 Intrusion Detection System (IDSM) ................................................................................................. 70
4.3.8 JTAG Protection .............................................................................................................................. 71
4.4 Software Update ................................................................................................................................. 72
4.4.1 Development Phase ........................................................................................................................ 72
4.4.2 Bootloader ....................................................................................................................................... 72
4.4.3 Bootloader updater .......................................................................................................................... 73

10033136 SACID
4.4.4 Interaction between Application and Bootloader. ............................................................................ 73
4.4.5 HSM Updater (vHsmUpdater) ......................................................................................................... 73
4.4.6 Update Mechanism of logical blocks in Program (ROM) Memory .................................................. 74
4.4.7 Flash data security .......................................................................................................................... 75
4.5 System Behavior on the network ........................................................................................................ 75
4.5.1 CAN ................................................................................................................................................. 76
4.5.2 ETHERNET ..................................................................................................................................... 76
4.5.3 LIN ................................................................................................................................................... 76
4.6 System Interfaces ............................................................................................................................... 77
4.6.1 JTAG Interface ................................................................................................................................ 77
4.6.2 XCP ................................................................................................................................................. 77
5 Dynamic Architecture ................................................................................................................................... 78
5.1 ECU (SACID Hardware) States .......................................................................................................... 78
5.2 Data Flow ............................................................................................................................................ 84
5.3 Scheduler ............................................................................................................................................ 84
5.4 Task Definition:.................................................................................................................................... 85
5.4.1 Start-up Task ................................................................................................................................... 85
5.4.2 Idle Task(Background Task) ........................................................................................................... 85
5.4.3 Tasks Details ................................................................................................................................... 85
5.5 Task Mapping ...................................................................................................................................... 86
5.6 Interrupts ............................................................................................................................................. 87
5.7 OS Hook Functions ............................................................................................................................. 88
5.7.1 Error Hook ....................................................................................................................................... 88
5.7.2 Pre-Task Hook ................................................................................................................................ 89
5.7.3 Post-Task Hook ............................................................................................................................... 89
5.8 Resource Consumption Estimates for all Components ...................................................................... 90
5.8.1 Memory Estimate ............................................................................................................................ 90
5.8.2 CPU Load Estimation ...................................................................................................................... 90
5.8.3 CPU Load Measurement ................................................................................................................. 90
5.9 Variant Handling .................................................................................................................................. 91
5.10 Critical Functional Requirements ........................................................................................................ 92
5.10.1 Timing Requirements .................................................................................................................. 92
5.10.2 Security Requirement – Isolation ................................................................................................ 92
6 Memory Map ................................................................................................................................................ 94
6.1 Program(ROM) Memory ...................................................................................................................... 94
6.2 Data Memory ....................................................................................................................................... 94
6.3 RAM Memory ...................................................................................................................................... 94
6.4 Data storage ........................................................................................................................................ 95
6.5 Data buffer........................................................................................................................................... 96
7 Configuration and Build Process ................................................................................................................. 97
7.1 AUTOSAR Configuration Tools........................................................................................................... 97
7.2 Compiler and Linker ............................................................................................................................ 98
7.3 Build Environment ............................................................................................................................... 98
8 Standards and Reference Documents......................................................................................................... 98
9 Definitions and Acronyms ............................................................................................................................ 98

10033136 SACID
1 Scope and Project Information

The objective and scope of this Software Architectural Design (SAD) is to define and document the software
architecture of the 10033136 SACID (Smart Actuator Charger Interface Device) project. It specifies requirements
regarding software modules and software blocks. It describes how functionalities under constraints have been
implemented.
1.1 Intended Audience

Customer Dr. Ing. h.c. F. Porsche Aktiengesellschaft
SW Project Manager Sebastian Grzeskiewicz , Dariusz Janicki
EE / SW Project Lead Zbigniew Wróbel / Meet Desai
SW / SYS Architect Aravind Vazhathattil / Karol Matys
System Engineers Pavan Kumar, Piotr Piątek
Cybersecurity Engineer M, Bharath Kumar
Software Engineers Kaviarun Kandasamy K , Venkata Satyanarayana Reddy , Kiran R,
Puneethshree Ajjahalli , N Pavithra V , Venkatesh Bugata , Hamsini C ,
Nandagopal S,
1.2 Project Information

Item Information Description
Customer Dr. Ing. h.c. F. Porsche Aktiengesellschaft
Unit Name SACID Smart Actuator Charging Interface Device
Car Type Porsche Macan
Model Year 2022
APTIV Project Name PO10CG 10033136 MY2022 Porsche SACID EV CG
PO10CG
APTIV Project ID 10033136
Microcontroller SPC584C74E5EEC 3MB(ROM) ,320KB(RAM) , 128KB (DFLASH)
FuSi Level ASIL A
Communication Bus CAN , LIN , ETHERNET , PLC
Network behavior ACTIVE
Terminal Supply KL_30
Operating System MICROSAR OS AUTOSAR Osek Os , Supplier : Vector
Bootloader Vector Flash Boot Loader Supplier: Vector
OBD Relevance Secondary OBD
Diagnostic Class DK4 Diagnostic Class 4

10033136 SACID
2 Functional Description
2.1 Overview
SACID (Smart Actuator Charger Interface Device) is a Vehicle to Grid (V2G) communication interface for
charging and discharging of electric vehicles. SACID act as a Power Line communication gateway between
HCP5 and Charging infrastructure. SACID support ISO15118 , CCS1 , CCS2 , CHAdeMO and China GB/T.
SACID communicate with HCP5 (central computer) via CAN-FD. Optionally there is an Ethernet .
2.2 System Hardware Block Diagram
Figure 1 : System Block Diagram
The SACID module contains following main hardware components:
➢ Microcontroller
o ST Chorus 4M SPC584C – Handle all communication devices, sensors and actuators
➢ Communication devices
• Ethernet Transceiver (TJA1101) connecting Microcontroller to Ethernet lines
CAN Transceiver TJA1042 for CHAdeMO CAN
• SBC with CAN and LIN Transceiver for CAN-FD and LIN communication.
➢ System Basic Chip (SBC)
• Infineon TLE9262QX
▪ Supply for the microcontroller
▪ High-speed CAN Transceiver supporting CAN-FD
10033136 SACID
▪ Lin Transceiver
▪ SPI interface for control and monitor the SBC
➢ H Bridge DRV8703
➢ Power Line Communication
Qualcomm QCA7005 – Establish power line communication with charging infrastructure.
Microcontroller(SPC584C) communicate with QCA7005 via SPI protocol.
Master : Microcontroller(SPC584C) , Slave : QCA7005
2.3 Software Block Diagram
Figure 2: Software Block Diagram
SACID ECU is responsible for the following

• Establish the SLAC process on the Control Pilot Line as per ISO15118-3
• Establish the ISO Power Line communication with the charging infrastructure as per ISO 15118 or
DIN70121.
• Establish communication on the CAN channels for GB/T inlets as per GB/T standards.
• Establish communication on the CAN channels for CHAdeMO inlets as per CHAdeMO standards.
• Control the LEDs connected to the hardware to indicate the charging status (blink, steady , pulsate ,
flash).
• Read the push button feedback
• Detect and control the position of charging plug lock motor.

10033136 SACID
• Detect and control the position of flap lock motor (connected via both electronically and LIN).
• Detect different type(CCS1/Type1 , CCS2/Type 2 , GB/T) of charging plug connected on the proximity
pin.
• Measure the Frequency , Duty cycle and Voltage on the control pilot line to determine the various IEC-
61851 states of the EVSE.
• Communicate with HCP5 via CAN Bus
• Establish ethernet communication to create communication for E-mobility and EE-Bus
Protocols(according to EEBus standard) to exchange data between EV and EVSE.
2.4 Variant Information for SACID System
Table 1 : SACID Variant Information
2.5 Carry-over parts from other Projects
SACID is a first power line communication gateway project in APTIV.This is the first project where APTIV use
Vector Vehicle to Grid (V2G) solution. Hence most of the components of this project are newly developed.
Following is one of the component re-used from a previous project
1. System Supervision module (SysSup) - See section 4.1.2.3.10.9 for details about this module.
2.6 New concepts and Technologies
Following new Technologies/solutions are used in the SACID project.
1. International Standards for Vehicle to Grid communication ISO15118 , CCS1 , CCS2 , CHAdeMO and
China GB/T
2. Vector Vehicle to Grid (V2G) solution - V2G solution provides the technology needed to establish the
communication with external charging infrastructure via Power Line Communication (PLC).

10033136 SACID
3 Micro-controller Resources
3.1 MCU Description
The Microcontroller used in SACID hardware is STM Chorus SPC584C74E5EEC.
Following are the available resources of SPC584C74E5EEC.
Resource Name Value Description
PFlash 3MB Non-volatile flash memory for program and constants

storage. Divided into several banks each connected to a
CPU
DFlash 128kB (4x32k) Non-volatile memory used to emulate EEPROM
RAM 320kB Total SRAM size of all Memory type available

• 256kB System RAM
• 64kB local CPU RAM
Core 1 PPC Core e200z4 @ 120MHz

1 HSM core • 8k-I / 4k-D Caches
• FPU
• MPU
e200z0 HSM core @60 MHz
Timer STM 1 System Time , one 32 bit free running timer for the core.
CAN Nodes 8 Two CAN sub system each having 4 nodes
Ethernet 1 One Ethernet controller 10/100 Mbps
LINFlexD 18
SPI 8
ADC 5
3.2 Microcontroller peripherals

Internal Microcontroller peripherals used in SACID are detailed below.

10033136 SACID
3.2.1 PLL
Internal system and peripheral clocks are generated from PLL.
Following table list the clock freequency shall be configured for different peripherals.
Peripherals Clock Reference Frequency
System clock PLL 120 Mhz
CAN 0 ClkRefPnt_XOSC 16 Mhz
CAN 1 ClkRefPnt_XOSC 16 Mhz
LIN 0 LIN_CLK0 40 Mhz
LIN 1 LIN_CLK0 80 Mhz
EMIOS 1 EMIOS_CLK 80 Mhz
SPI DSPI_CLK0 40 Mhz
HSM HSM_CLK 90 Mhz
3.2.2 CAN- FD
SACID communicate with HCP5 through CAN FD communication .CAN communication (Microcontroller
and CAN transceiver) is qualified CAN FD with 2Mbits/s transmission and payload longer than 8-bytes.
CAN Oscillator Frequency is 16Mhz
CAN bit timing: Arbitration Phase BTL (number of time units) 16
TSeg_1 1
TSeg_2 3
Sample point 81
SJW 1
Baud Rate Pre-scaler (BRP) 2
CAN bit timing: Data Phase BTL (number of time units) 8
TSeg_1 1
TSeg_2 1
Sample point 70
SJW 1
Baud Rate Pre-scaler (BRP) 1
Table 2 : CAN Bit timings
• SACID support wake up by CAN messages
• CAN network go to sleep if there are no NM messages from HCP5
• SACID is an active node in the CAN network and generate NM messages after it wake up
• SACID support the software update through CAN
3.2.3 LIN
The SACID is a LIN master. LIN0 and LIN1 are used. LIN is configured for 19.2Kbits/s transmission
Bit of sample timing tBFS 3.25 us
(LIN2.2) tEBS 22.7 us
tLBS 29.29 us
SACID connected to electric flap, PUSH buttons (ETSA) & LEDs through LIN nodes in few variants(see
section 2.4 for details of variants support LIN).

10033136 SACID
Each LIN line (LIN0 or LIN1) connected to single connector, like AC and DC respectively .
Variants LIN0 LIN1

Europe Combo Connector
Japan AC Connector DC connector
• SACID support both LIN wake up and sleep.

• SACID gateway all the LIN application data to HCP5 and vice versa without losing any data.
• SACID initiate initial LIN sequence to communicate with LIN nodes
• SACID use frames 60 (0x3c) and 61 (0x3d) to carry diagnostic data(product and supplier ID etc)
3.2.4 ETHERNET
SACID is also connected with ConMod(Wireless LAN) via Ethernet. SACID use 100BASE-T1 Ethernet
PHY.
3.2.5 SPI
Microcontroller shall use SPI to communicate with the following external peripherals.
1. System Basic Chip TLE9262BQXV33
2. PLC IC QCA7005
3. Motor control Chip DRV8703
SPI Device Baud rate Physical Unit Chip Select
TLE9262BQXV33 1MHz DSPI0 PCS1
QCA7005-AL33 8MHz DSPI1 PCS0
DRV8703-Q1 4MHz DSPI0 PCS7, PCS0, PCS0
3.2.6 ADC
SACID use 12 Bit ADC to convert voltage into ADC counts. Following components on SACID is connected
to ADC Inputs.
1. Temperature Sensor
2. Proximity Detection
3. CC1 and CC2 pins for GB/T.
4. LED
5. Pushbutton
6. Control Pilot
7. Battery
8. Connector Lock

10033136 SACID
3.2.7 Timer Modules (System Timer and GPT)
Following timers shall be used
Usage Timer Type Channel Resolution
OS time tick STM2 , 32 bit Timer Channel 0 1 tick –> 1ms
Time base for CPU Load Periodic Interrupt Channel 0 10000 ticks -> 1ms
measurement Timer
3.2.8 PWM
SACID shall use the following PWM configuration for LED and control Pilot.
Control Pilot
Direction Channel Duty Cycle Period
Input EMIOS_1_CH_03 0-100% 950-1050 Hz
LEDs
Direction Channel Duty Cycle Period
Output EMIOS_1_CH_22 0-100% 200 Hz
3.2.9 Digital IOs

Direction Port Pin Usage
Output PF[12] H-Bridge , Driver Disable
Output PF[11] H-Bridge , Driver Sleep
Output PA[10] Plug lock Control
Output PA[11] Plug lock Control
Output PK[1 ] PLC(QCA7005) Reset
3.2.10 Flash
Following flash memory shall be used . See section 7 for more details of address range of each memory
region.
Usage Memory Total Size Life Cycle

10033136 SACID
Bootloader , Application Program Flash 3 MB 100K Cycle

software , Hardware
configuration (OTP) ,
QCA7005 firmware
Storage of Non Volatile Data Flash Block 128 KB 250K Cycle
Data
HSM Firmware Secured Code Flash 144KB 100K Cycle
Block
Secured Data Secured Data Flash 32 KB 100K Cycle
Block
3.2.11 RAM
Usage Memory Size
Data and bss section System RAM 256KB
Stack Local RAM 64KB
Data and bss section- HSM HSM RAM 32 KB
firmware 8KB – Standby RAM
3.3 Hardware fallback Strategy
Following are the possible options available if project falls in to the scare of Micro-controller resource due to
the additional features or components which are not planned .
1. Insufficient Computing Power
To increase the computing power following are the two options
- Use high clock frequency microcontroller from the same family - SPC58EC80 with clock speed of
180Mhz
Change needed in the software :
a. MCU(Clock and PLL) and OS configuration shall be updated.
- Increase the number of cores - Use dual core Micro-controller SPC58EC80 (Two z4 core @ 180Mhz)
Change needed in the software -
a. Dual core OS shall be purchased from Vector.
b. Identify component which can run independently on second core and move to the second core
2. Insufficient ROM or RAM
Use ST Microcontroller 4M series SPC58EC80 which has 4MB ROM and 512 KB RAM.

10033136 SACID
4 Static Architecture Description

4.1 Architecture Definition
4.1.1 Alternate Architecture Evaluation
Autosar architecture is chosen for SACID. This is due to the following

1. PAG requirement is to use Autosar 4.2.2 Architecture
2. SACID need Vehicle to Grid (V2G) solution for PLC communication. Only Vector has Vehicle to Grid
solution available which meet PAG requirements and it is based on Autosar architecture.
Within Autosar architecture both single core and multicore options are evaluated . Based on the following
evaluation result single core Autosar solution is chosen for SACID.
1. No Software component in SACID can be moved to second core which can run independent
Following components are evaluated
a. Ethernet - As there is a gateway from Ethernet to CAN , moving Ethernet to second core will
increase the gateway latency.
b. V2G - V2G has dependency to Ethernet module and SPI module , hence V2G cannot run
independently in second core.
c. SWCs components - All the application components has dependency to CAN , hence moving this
components to second core will create IOCs (Inter Core communication) and that will affect the
throughput of the system.
4.1.2 Main software structure

The software of SACID is structured in three components.
• Bootloader
The boot loader is a stand-alone program. It is compiled, linked, and downloaded to the ECU separately on
production line. The boot loader and Application SW never run simultaneously. The bootloader is
responsible for downloading software modules (like application software) to SACID memory areas (Flash
ROM or RAM).
• Hardware configuration Area

Contains hardware/ECU identification and compatibility data, ECU serial number, if necessary hardware
calibration etc. It does not contain executable code. The Production data Area is downloaded to the ECU on
production line and cannot be modified, cleared or overwritten by the Bootloader.
• Application software
The application software is the software module which is normally active during normal SACID operation
and contains biggest part of functional software. Application software can be downloaded to µC memory by
the Bootloader.

10033136 SACID
• HSM Firmware
HSM firmware is executed on the hardware security module of the microcontroller. HSM firmware
implement the required crypto algorithms .
Table below have the details of various components of SACID software and component responsible
Component Name Component Responsible

Bootloader and Bootloader Updater Vector
HSM Firmware and Hsm Updater Vector
QCA 7005 Firmware Qualcomm
Application software
BSWs and MCAL
Autosar BSWs , Can Driver , Lin Driver , Ethernet Driver Vector
Autosar OS Vector
Autosar RTE Vector
Autosar MCALs ST Electronics
Mcu, Port , Gpt, Spi , Dio , Fls, Adc, Icu , Pwm ,Wdg
CDDs
V2G Software Vector
SCC, TLS, EXI , XMLSecurity , DNS , HTTP

CddNpmGen2 Vector
PLCKS APTIV
VKMS Porsche
SOK Porsche
SysSup APTIV
Cdd_CpuLoadMonitor APTIV
Software Components (SWCs)
SFD Porsche
KS Porsche
TempSensor (ALST) APTIV
CPE (Control Pilot Evaluation) APTIV
AVS APTIV
VAS APTIV
PPE APTIV
LKPE APTIV
VALK APTIV
ISOND APTIV
LED APTIV
CCDC APTIV
CDOE APTIV
LKAE APTIV
Table 3 : SACID components

10033136 SACID
4.1.2.1 Bootloader
The boot loader is a stand-alone program. It is compiled, linked, and downloaded to the ECU separately on
production line. The boot loader and Application SW never run simultaneously. The bootloader is responsible
for downloading software modules (like application software) to SACID memory areas (Flash ROM or
RAM).Bootloader is started first on a power-up of the SACID. Bootloader will verify the integrity of the application
software which is stored in the application memory areas. Once the integrity of application software is verified
bootloader will give the control to application software. The Bootloader is software product delivered by Vector
to APTIV where it is customized and adapted for SACID.
4.1.2.2 Hardware configuration Area
The area contains data specific for particular ECU and ECU variant, such as ECU serial number, hardware
variant identification, if necessary hardware calibration data. The data are flashed to Flash ROM only ones on
production line and cannot be modified after that.
Block Address Size in bytes

Header 0x00FC0000 32
ECU Serial Number 0x00FC0020 16
Hardware Identification Block 0x00FC0030 32
Table 4 : Memory map of Hardware Configuration Area
Field Name Offset Size in bytes Description

HW Variant Name 0x00 4 Variant name in ASCII:
“BA” - RdW/NAR Basis Combo
“BB” - China /Japan Basis
“BC” - RdW/NAR Basis AC
“HA” - RdW/NAR High
“HB” - China /Japan High
HW Variant Index 0x04 4 Variant Id in ASCII:
“1 ” - RdW/NAR Basis Combo
“2 ” - China /Japan Basis
“3” - RdW/NAR Basis AC
“4” - RdW/NAR High
“5” - China /Japan High
HW Major Version 0x08 4 Major Version name in ASCII in range
HW Minor Version 0x0C 4 Minor Version name in ASCII
HW Version Index 0x10 4 Version id in hex:
Table 5 : Content of Hardware Identification blocks
4.1.2.3 Application software

10033136 SACID
SACID software is designed as per Autosar 4.2 / 4.3 Layered Architecture.
Below diagram graphically describe how the software is structured with software layers, modules and blocks as
per the AUTOSAR Architecture.
Figure 3 : SACID Architecture
Note : Crypto modules are based on Autosar 4.3 . All other BSW module are based on Autosar 4.2.
• Application layer
The layer where all functional application components are located. The software architecture of application
layer is “component style” in opposite to “layered style” in Basic Software.
Normally all the application components do not communicate each other directly. All communication is
handled via RTE.
• Runtime Environment layer (RTE)
RTE is a layer providing communication services to the application software components.
• Basic Software layer
BSW is divided into Operating System (OS) and Services modules , ECU abstraction with I/O Hardware
Abstraction (IoHwAb) and Complex Device Drivers.
The OS and Services Layer is the highest layer of the BSW which applies also for its relevance for the
application software.
The ECU Abstraction Layer interfaces the drivers of the Microcontroller Abstraction Layer. It offers an API
for access to peripherals and devices regardless of their location and their connection to the

10033136 SACID
microcontroller. Especially I/O Abstraction (IoHwAb) provides standardized interfaces to access sensors
connected via analog and digital inputs and/or PWM outputs for control actuators.
Complex Device Drivers spans from the MCAL to the RTE. It provides the possibility to integrate special
purpose functionality, e.g. drivers for SBC , PLC IC (QCA7005) .
Autosar basic software provides the following needed for SACID software
➢ Communication (CAN , LIN and ETHERNET)
➢ Diagnostic
➢ Memory handling
➢ Watchdog handling
• Microcontroller Abstraction layer (MCAL)
The lowest layer of Basic Software. It contains internal drivers, which are software modules with direct
access to microcontroller and internal peripherals. It’s aim is to isolate higher layers from microcontroller
dependencies.
• Complex Device Driver
Apart from standard Autosar BSW modules and MCALs , there are some additional hardware dependent
modules like SBC , PLC IC (QCA 7005) are needed for SACID. These modules are implemented as Complex
Device driver. Autosar guidelines are followed for implementation of such modules.
• Microcontroller
this layer shall represent the hardware of the microcontroller
All Autosar BSW modules, RTE, OS, MCALs and Autosar configuring Tools are delivered by Third Party
Company. See Table 15 for details of Autosar BSW supplier.
Tool Name Supplier
Davinci Configurator and Developer Vector
EB tresos (tool used for the configuration of MCALs) ST Electronics
Table 6: Autosar Configuration Tools
Apart from standard Autosar BSW modules and MCALs , there are some additional modules are needed here
to satisfy the ECU requirements. These modules shall be implemented as either Complex Device driver or as
standard driver modules. Autosar guidelines shall be followed for implementation of such modules.
Following modules(Standard Software) are Provided by Porsche which shall be integrated
Module Name Type Version

VKMS CDD 2.4.0
SOK-FM CDD 2.1.0
SFD SWC 1.1.0

10033136 SACID
KS SWC 4.4.0
4.1.2.3.1 MCAL
Following MCAL modules shall be used in SACID software to have access to the ST Chorus SPC584C74E5
peripherals .
1. MCU
2. PORT
3. GPT
4. SPI
5. DIO
6. FLS
7. ADC
8. ICU
9. PWM
10. CAN
11. LIN
12. WDG
13. ETHERNET
Standard Autosar MCAL modules like Mcu, Gpt, Fls,Spi, Adc, Dio and Port are provided by ST Electronics.
MCAL configuration tool (EB tresos) is used for configuring these modules as per the requirement and the
hardware schematic.
MCU – Mcu module provides service for initialization of the core Mcu functionalities listed below
- Manage CPU clock and peripheral clock
- MCU mode handling
PORT – Microcontroller Port properties are managed by the port module. Following properties can be configured
using the port driver
- Port Pin direction
- Port Pin Initial value
- Port Pin Mode
- Port Pin alternate value
DIO - This module works on pins and ports which are configured by the PORT driver.
All services in DIO driver shall be synchronous (no buffering of request/value). DIO driver is used to read
or write GPIO values.
GPT - The GPT driver is part of the microcontroller abstraction layer (MCAL). It initializes and controls the
internal General Purpose Timer(s) (GPT) of the microcontroller.
GPT driver provides services and configuration parameters for starting and stopping hardware timers,
getting timer values, controlling time triggered interrupt notifications.

10033136 SACID
ADC - The ADC Driver initializes and controls the internal Analogue to Digital Converter Unit(s) of the
microcontroller.
ADC Module in the microcontroller provides both 10 bit and 12 bit resolution data conversion.
ADC Driver shall provide services to start and stop a conversion to enable and disable the trigger source
for a conversion.
PWM- The PWM driver provides functions for initialization and control of the microcontroller internal PWM stage
(pulse width modulation).
PWM module generates pulses with variable pulse width. It allows the selection of the duty cycle and
the signal period time.
FLS - Flash driver module is used for flash read , write and erase operation .Non-volatile data will be stored
and retrieved using the services provided by the Fls module.
CAN - CAN driver shall initialize the CAN controller peripheral and provide services for data transmission,
reception and bus off handling etc.
SPI - SPI driver shall initialize the SPI peripheral and provide services for data transmission and reception.
Microcontroller (ST Chorus) communicate with Power Line IC (Qualcomm QCA 7005), SBC(TLE9273)
via SPI protocol.
ICU – ICU Driver controls the input capture .In SACID there is an interrupt line connected to QCA7005 chip.
Ethernet driver for QCA7005 need an interrupt to be triggered when there in rising on this interrupt line. ICU
module shall be used for configuring this.
4.1.2.3.2 System Stack

In Application software the Ecu states are managed by System stack module. Following module part of the
system stack are mainly responsible for handling the ECU states.
1. Ecu State Manager (EcuM)
2. Basic Software Mode manager (BswM)
When Application software is started , the first module will be initialized is Ecu State Manager(EcuM). EcuM
manages the common aspects of ECU (SACID) states.
EcuM also responsible for
• Initialization of MCAL modules
• Initialization and de-initialization of OS , BswM and few BSW modules.
• Manage ECU during startup ,sleep and wakeup
• Manage all wakeup events
EcuM and BswM together implements the ECU mode management and application mode management.
BswM module main responsibility is to arbitrate mode request from application layer SW-Cs or other BSW
modules based on rules and perform action based on arbitration results.
10033136 SACID
As these modules mainly handle the mode management , the asynchronous runnables of these modules are
scheduled at period of 10ms.
Runnable Period
EcuM_MainFunction 10ms
BswM_MainFunction 10ms
Table 7 : System stack Modules Asynchronous Runnables
4.1.2.3.3 CAN communication stack
CAN communication requirements in SACID is implemented using Autosar CAN communication modules.
Communication Stack in AUTOSAR is a set of modules like COM (Services Layer), PDU Router(Services Layer),
CanIf (ECU Abstraction Layer) , Can Bus Drivers (MCAL Layer) . In addition to this there are modules like Can
State Manager (CanSM) , Network Manager(Nm, CanNM) and Can Transport Protocol(CanTp) modules in the
communication stack
cmp CommunicationStack
ComM Nm
«fl ow»
«fl ow» «fl ow»
Com CanSM CanNm
«fl ow»
PduR
«fl ow»
«fl ow»
CanTp
«fl ow»
«fl ow»
CanIf
«fl ow»
«fl ow»
CanDriv er
Figure 4: CAN communication modules

ComM module control the basic software module relating to communication stack , collect the bus
communication access request from the users and handle the network management.
CanSM module is responsible for the control flow abstraction of CAN networks. It changes the communication
modes of the can network depending on the mode request from the ComM module.

10033136 SACID
Nm module acts as an adaptation layer between can network management (CanNm) and the ComM modules.
Network management (Nm) module also responsible to coordinate the synchronized sleep/shutdown of Ecus
connected to the communication bus.
CanNM module main purpose is to coordinate the transition between normal operation and bus sleep mode of
the CAN network.
AUTOSAR COM is a module between the RTE and the PDU Router. It is responsible for providing a Signal level
access to the application layer and a PDU level access to the lower layers independent of the protocol. It packs
the signals to a PDU at the transmitter and unpacks the received PDU to provide a signal level access to the
application at the receiver. COM is responsible for a signal/signal group level gateway. It maps a received
signal/signal group to a transmit signal/signal group to be gatewayed
PDU Router is a module responsible for routing the PDU to the respective Bus Specific Interface modules(CanIf).
PduR is also responsible for PDU level gateway. PduR module can also interact with Cdd modules .
CanIf module provides standardized interface for all upper layer which require CAN communication. These
includes the transmission and reception of messages and the state handling of controller as well.
CanTp module is mainly used to segment and reassemble CAN-IPDUs longer than 64 bytes (in the case of
CAN-FD) and handle the transmission with flow control in the case of segmented messages.
Most of the above modules does their functionality in Asynchronous manner. Hence each module have
runnables which needs to scheduled periodically.
The period of these runnables depends on message period , overall CPU load etc.
To have better balance of CPU load and to support messages with periodicity of 5ms or more , the main functions
shall be scheduled with a periodicity of 5ms.
Some of the state manager modules like ComM , CanSM shall be scheduled with period of 10ms. Because these
modules are not involved during transmission and reception hence scheduling these modules with period of 5ms
is not required.
Runnable Period
Com_MainFunctionRx 5ms
Com_MainFunctionTx 5ms
CanTp_MainFunction 5ms
CanSM_MainFunction 10ms
ComM_Mainfunction 10ms
Table 8 : CAN BSW Modules Asynchronous Runnables
4.1.2.3.3.1 CAN Wakeup and Sleep Handling
• SACID is ACTIV node on the CAN network.

• CAN communication wakeup can happen,
o When NM messages are received from other node.
o Wakeup due to other wakeup sources
10033136 SACID
CAN NM starts a transition to Repeat Message state only if the message is in the range of valid CAN-NM. NM-
Identifier in the Extended format (29-bit ID) 0x1B000000 - 0x1B0003FF
CAN Sleep:
Whenever there are no NM messages from other node for duration of 400ms , CAN communication from SACID
needs to be stopped(bus sleep) following proper network management state transitions.
4.1.2.3.4 Ethernet Communication stack.
TCP/IP based communication requirement in SACID software is implemented using Autosar Ethernet
modules.
Figure 5: Ethernet communication modules
SoAd module create an interface between an Autosar communication module like PduR and socket based
TcpIp stack. It will map I-PDU Ids to socket connections and vice versa.
TcpIp provides socket interface based on internet protocol (IPV4 and IPV6) on ethernet. Autosar TcpIp stack
support both TCP and UDP protocols.
EthIf module provides to upper layer(SoAd) an hardware independent access to ethernet controller.
As the ethernet communication have to handle data with a speed up to 100mbps , asynchronous runnables
have to be scheduled more frequently.
Currently the period of Asynchronous runnables of Ethernet modules are defined as below . This might need
some update later based on data load and CPU load.
Runnable Period
Eth_MainFunction 5ms
EthIf_MainFunctionRx 5ms
EthIf_MainFunctionTx 5ms

10033136 SACID
EthIf_MainFunctionState 5ms
TcpIp_Mainfunction 5ms
SoAd_Mainfunction 5ms
EthSM_MainFunction 5ms
Table 9 : Ethernet BSW Modules Asynchronous Runnables
4.1.2.3.5 LIN Communication stack

Some of the vehicle components (Push button and flap on the vehicle charging socket) are connected to
SACID ECU via LIN protocol. LIN communication in SACID software is implemented using Autosar LIN
modules. Autosar stack include LinSM , LinNM , LinIf and Lin Driver.
cmp LinCommunicationStack
ComM Nm
«fl ow»
«fl ow» «fl ow»
Com LinSM LinNm
«fl ow»
PduR
«fl ow»
«fl ow»
LinIf (include LInTp)

«fl ow»
«fl ow»
LinDriv er
Figure 6: LIN communication modules
LinSM module control the communication status of Lin network . Also responsible for handling the schedule
change request.
LinNm module coordinate the transition between normal operation state and bus sleep mode of the network.
LinIf module execute the currently selected schedule for each LIN bus SACID ECU is connected. And also
responsible for switching schedule table when requested by the upper layer.LinIf support the behavior of a
master in the LIN 2.1 specification. Transport protocol (LinTp) is included in the LinIf module.

10033136 SACID
Most of the above modules does their functionality in Asynchronous manner. Hence each module have
runnables which needs to scheduled periodically.
The period of these runnables depends on schedule table , overall CPU load etc. To have better balance of CPU
load and to support schedule table 5ms or more , the main functions shall be scheduled with a periodicity of
5ms.
Runnable Period
LinIf_MainFunction 5ms
LinSM_MainFunction 5ms
Table 10 : LIN BSW Modules Asynchronous Runnables
4.1.2.3.6 Operating system
Vector Microsar OS (Autosar OS) is used in SACID .And the MICROSAR OS used in SACID support only single
core. Autosar OS is based on OSEK specification with addition of more protection features. OSEK OS is an
event triggered operating system. This provides flexibility to design the system which support both polling and
event based scheduling.
Scalability class SC4
Conformance class BCC1 , ECC1
Microsar OS support all the scalability class. But in SACID OS is configured for BCC1 and ECC1.
Microsar OS used here support up to scalability class 4. As we need memory protection and timing protection
OS is configured to support the features according to scalability class 4 .There is no dynamic creation of task at
runtime and no dynamic memory management is supported in the operation system . All tasks are configured
during the compilation time.
OS module implements a specific stack concept. It’s possible to define different stacks and can be assigned to
tasks and ISRs. This enable each task and ISRs to have its own stack area.
4.1.2.3.6.1 Task
Application software runnables and asynchronous runnables of BSW are executed in task context. Based on the
execution requirement runnables are mapped to either basic task or extended task. All event-driven SWC
functions are assigned to extended and preemptive tasks. The Extended Tasks differ from the Basic Tasks by
being allowed using additional operating system services which may result in waiting state. Waiting state allows
the processor to be freed and reassigned to a lower priority task without the necessity to terminate the Extended
Task.

10033136 SACID
4.1.2.3.6.2 Interrupt
In SACID software all the peripheral interrupts are serviced after the OS initialization . Hence all the peripheral
interrupts are implemented as Category 2 interrupts. That means in this case OS is responsible for the interrupt
handling like stack allocation to interrupt , interrupt priority handling , nesting of interrupt , invocation of interrupt
service routine etc.
4.1.2.3.7 IO Hardware Abstraction (IoHAB)
The Io Hardware Abstraction module provides decoding, filtering and data exchange services from MCAL to
RTE. The IoHAB has no direct access to the hardware. It provides a signal based interface to the upper software
layer. It performs static abstraction and inversion (if needed) of values according to their physical representation
at the inputs/outputs of the ECU hardware (compensation of static influences caused within the path between
ECU IO and Microcontroller pin, e.g. voltage divider, hardware inversion).
The IoHAB module handles MCAL modules such as DIO, PWM, ADC. Hence, the IoHAB is modularized into
different components which enable the handling of one group of IOs. It comprises of the following components.
1. IOHAB_Discrete
This sub-component handle all the discrete inputs and outputs.
Discrete inputs are classified as below in IO hardware Abstraction
a. Direct Inputs – Here the Port Pin is directly read
b. Buffered Inputs – Input values are read cyclically and debounced. The value provided to upper
layers is validated.
Digital Outputs are classified as below in IO Hardware Abstraction.
a. Direct Outputs – Here the Port Pin is directly written

b. Buffered Outputs - Output value is written to an internal software buffer. The content of this
software buffer is cyclically written to output pin. Ensures functional safety by refreshing the
status of outputs cyclically
2. IOHWAB_Analog
This sub-component handle the Analog inputs .
Analog Inputs are classified as below in IO Hardware Abstraction.
a. Direct Inputs – Here the ADC Channel is directly read
b. Buffered Inputs – ADC Channel values are read cyclically and debounced. The value provided
to upper layers is validated.
3. IOHWAB_Pwm
This sub-component handle the PWM outputs to set period and duty cycle for the Pwm channels on the
controller.

10033136 SACID
IOHWAB MCAL
IOHWAB
IOHWAB_Analog ADC
IOHWAB_Discrete Dio
IOHWAB_Pwm PWM
Figure 7: IoHwAb Components
IoHWAB module have one init function and few runnables which is scheduled in OS task with period of 5ms.
Runnable Period
IoHwAb_AnalogIn 5ms
IoHwAb_DiscreteIn 5ms
IoHwAb_DiscreteOut 5ms
IoHwAb_PWMIn 5ms
Table 11 : IoHwAb Asynchronous Runnables

10033136 SACID
Init() DIO
IOHWAB
OS_5ms_Task ADC PWM
Figure 8 : IoHwAb Interaction Diagram
4.1.2.3.8 Non Volatile Memory Handling
SACID shall use 128KB internal data flash available in the Microcontroller for storage of data permanently.
Autosar Memory modules (NvM, MemIf, Fee and Fls) provides services to store data consistently in the data
flash. Data flash available in the Microcontroller ST584C is sector erasable. Hence a Eeprom emulation
mechanism in implemented in the Fee module there by provide more number of erase/program cycles than the
typical flash erase /program, cycle of 250K.
To support the emulation mechanism following configuration shall be done in the Fee module.
One Fee cluster group with two Fee clusters shall be configured
Each fee cluster shall have one sector of size 64KB
Each Fee logical block shall be mapped to the Fee Cluster group.
Figure 9: Data Flash Configuration

Data consistency – To ensure data consistency on data stored in the data-flash 16 bit CRC algorithm
provided by the CRC module shall be used .
SW compatibility with the memory layout – This is achieved by using the Configuration ID feature available
in the NvM modules. A unique configuration ID corresponds to the NvM configuration also stored in the

10033136 SACID
nonvolatile memory whenever there is change in the configuration. Compatible means that the structure and the
length of all blocks are the same. Within a block dummy signals or an area is used to have some margin for
keeping the block compatible for some time. But when a complete new block is added then the structure of the
NvRAM is incompatible. The same is valid when the length of one block changes. Then the complete structure
of the NvRAM is incompatible to the former one. During startup there is an algorithm which checks the
compatibility by comparing the Config ID and in case of non-compatibility then the default values will be loaded
instead of data from the data-flash. Each time during a software update configuration ID shall be change if there
is a layout change due to which previous written data cannot be used.
Default value - All blocks need to have default values configured. This is needed to copy the default values into
the RAM in case there is a problem detected.
Non-volatile memory read during STARTUP and SLEEP

During SACID startup stored data from data-flash shall read and copied to the corresponding RAM location .
This shall be done before initialization of BSW modules which has dependency to NvM and Software
Components which their data in the non-volatile memory.
NvM_ReadAll service provided by NvM shall be used for this. This service will trigger read data from multiple
physical blocks hence the execution time is high. To reduce the impact on startup time this operation shall be
done in a waiting loop before OS starts.
Figure 10: Nonvolatile Memory read during STARTUP

10033136 SACID
4.1.2.3.9 UDS Diagnostic
Vector modules Diagnostic Communication manager(Dcm) and Diagnostic Event Manager (Dem) shall be used
for handling diagnostic services and fault management according to UDS standards. Diagnostic functionalities
according to each DIDs, Routines controls etc shall be implemented in a separate application component
(AptivDiagSwc).Dcm module shall interact with this component to invoke operations or fetch data according to
the UDS services requested. For security unlock DCM module shall interact with SFD module.
Figure 11: Diagnostic Modules Interaction
4.1.2.3.10 Complex Device Driver

4.1.2.3.10.1 Smart Charging Communication (SCC)
SCC module is implemented by Vector. Aptiv is responsible for the integration of this module.
SACID use PLC Technology (Power Line Communication) to communicate with the charging station .In this
system data stream is modulated onto power lines.
Vector Vehicle to Grid (V2G) solution provides the technology needed to establish the communication with
external charging infrastructure via PLC. And the V2G solution use Autosar Ethernet and Tcp/Ip stack for the
communication which provides socket communication over IP for TCP and UDP .Vector V2G modules are
implemented as CDD modules and Vector provides this modules as extension to their Autosar solution which
makes the integration possible with other standard Autosar modules.V2G support communication over internet
mechanism and protocols.
Vector V2G solution include Smart Charging Communication (SCC) module which support smart charging
functionalities according to the following standards.
1. ISO 15118

10033136 SACID
2. DIN SPEC 7021
Figure 12: Smart Charging Communication modules
SCC(Smart Charging Communication) – This module is responsible for smart charging communication
according to ISO15118 or DIN SPEC 70121.This module also support the following
AC : AC charging as well as the related Plug and Charge (PnC) and External Identification Means profiles.
DC : DC charging as well as the related Plug and Charge (PnC) and External Identification Means profiles.
ACD : Automatic charging Device
4.1.2.3.10.2 Transport layer Security (TLS)
TLS module is implemented by Vector . APTIV is responsible for the integration of this module.
This module contains a transport layer security client .TLS module provide certificate base encryption for the
Power Line communication between SACID and the charging station .TLS support certificate validation using
Online Certificate validation using Certificate Status Protocol (OCSP) stapling V1. TLS use crypto services
provided by the Autosar CSM (Crypto Service manager) for checking the certificate and signature.

10033136 SACID
Figure 13 : TLS Interaction Diagram

TLS module has two runnable which shall be scheduled periodically to perform the task in Asynchronous manner.
TLS_MainFunction Handle the handshake and other state dependent
actions. This function handles the different states to
establish TLS connections, parses stored root
certificates and CRLs, transmits data and forwards
data to the upper layer
Tls_MainFunctionLowPrio Main function to do all crypto computations. In case
of complex crypto calculations , the execution time
is very long.Hence this function shall be called from
a lower priority pre-emptive task.
4.1.2.3.10.3 Efficient XML Interchange Generator and Parser (Exi)
Exi module is implemented by Vector . APTIV is responsible for the integration of this module.
Efficient XML Interchange is used to interpret the XML documents and convert them to binary formats. This
makes processing and transmission of the files more efficient which economizes communication bandwidth.
SCC module use EXI services for encoding and decoding of XML files.

10033136 SACID
Figure 14 : EXI Interaction Diagram
Exi Provided the encoding possibilities to generate schema conform EXI streams according to the
schemata name spaces listed below. Supported XML namespaces are:
- urn:iso:15118:2:2010:AppProtocol as specified by ISO 15118-2 and DIN 70121
- urn:din:70121:2012:MsgDef as specified in DIN 70121
- urn:iso:15118:2:2013:MsgDef as specified by ISO 15118-2 (first edition)
- http://www.w3.org/2000/09/xmldsig# as specified by ISO 15118-2
- urn:iso:15118:2:2016:MsgDef as specified by ISO 15118-2 (second edition)
4.1.2.3.10.4 XML Security module (XMLSec)
XMLSec module is implemented by Vector. APTIV is responsible for the integration of this module.
XMLSec module is used to generate and validate XML signatures to EXI encoded data based on the W3C XML
security standard.

10033136 SACID
Figure 15 : XmlSecurity
4.1.2.3.10.5 PLC Communication Component (PLCKS)
Complex Device Drive PLC Communication (PLCKS) is responsible for carrying out the EVSE search process
using SLAC Process, as defined in ISO15118-3. It is also responsible for checking the Link Status of the on
board QCA7005 chip. The Status of the EVSE search process and Link Status is sent via CAN Communication
Figure 13: PLCKS Interaction Diagram
PLCKS module utilizes the callback APIs from QCA7005 Driver(EthTrcv CDD) provided by Vector to send
HomePlug GreenPhy compliant data packets to QCA7005 over the SPI.
PLCKS component has one periodic runnable which triggered every 10ms.

10033136 SACID
Dependency to Scheduler
Runnable Period
Plcks_Slac_SM 10 ms
4.1.2.3.10.6 Vehicle Key Management System (VKMS)
Vehicle Key-Management System has two parts , VKMS core component and VKMS adapter component.
VKMS core component is CDD module provided by Porsche. VKMS adaptor component is an add-on
implementation in the Vector HSM firmware.
VKSM Version 2.3.0 shall be used.

See section 4.3.5 for more details of usage of VKMS in SACID.
4.1.2.3.10.7 Sichere Onboard Kommunikation (SOK)
Sichere Onboard Kommunikation (SOK) is a CDD module provided by Porsche . SOK module provides
freshness value for the SecOC module.
SOK version 1.4.0 shall be used. See section 4.3.3 for more details of usage of SOK module in SACID.
4.1.2.3.10.8 NpmGen2
This CDD module is developed by Vector according to VW specification Knockout von Steuergeräten
Querschnittslastenheft LAH DUM.910.C.1.
APTIV shall integrate this CDD module delivered by Vector. This module will implements a mechanism to
avoid power consumption of the electronic control unit. This module monitor the bus activity and ECU activity .
Bus Knockout Monitoring
When communication is detected in any of configured bus this functionality is active and the configured Bus
Knockout timer will be active. When there is no bus activity and the timer expires , then Bus Knockout will be
triggered . When Bus Knockout is triggered , ECU reset will be triggered by calling the function
Appl_CddNpmGen2_BUS_Knock_out_PerformShutdown()
ECUKnockout Monitoring
When no communication is detected this functionality is active and the configured ECUKnockout timer will run.
Once the timer has expired , an ECU shutdown will be triggered by calling
Appl_CddNpmGen2_ECU_Knock_out_PerformShutdown()

10033136 SACID
4.1.2.3.10.9 System Supervision (SysSup)
SysSup(System Supervision) monitors the failures in the System. SysSUp module is implemented as Complex
Device Driver (CDD).
SysSup module capture the following error occur in the SACID ECU.
1. RAM ECC Error
2. Flash ECC Error
3. DataFlash ECC Error
4. Clock Failure
5. Charging Plug Error.
SysSup module trigger the ECU to ERROR state if any of this occur during the execution. If the state transition
to ERROR is due to ‘Charging Plug Error’ then SysSup module immediately trigger the ECU to enter into
SAFE state.In SAFE state all charging functionalities are deactivated and plugs are unlocked as safety
measure.
SysSup module shall have a periodic runnable which is executed in every 100ms to monitor the faults and
recover the ECU.
Runnable Period
SysSup_MainFunction 100ms
See section 4.2.2 for more details of fault handling by SysSup module.
4.1.2.3.10.10 CPU Load Measurement (Cdd_CpuLoadMonitor)
CDD module Cdd_CpuLoadMonitor reads the measured CPU load values from RTM module. When tester
request the CPU load via DID , AppDiagSwc shall fetch the CPU load values from Cdd_CpuLoadMonitor.
Figure 16 : Cdd_CpuLoadMonitor (CDD) Interaction Diagram

10033136 SACID
4.1.2.3.11 Description of the Software components
4.1.2.3.11.1 SFD
SFD from Porsche shall be used for implementing the role based access control.
See section 4.1.13.9 and 4.3.6 for details of SFD.
4.1.2.3.11.2 TempSensor (ALST)
The Temperature Sensor SWC (TempSensor) shall convert the ADC values measured by a temperature sensor
each at DC+, DC- and AC lines into temperature values.IoHwAb module provides the required interfaces to
read the ADC measurement values. Temperature sensor module shall not directly interact with ADC module.
TempSensor module shall also send the converted measured Adc value on CAN communication bus. It shall
use send receiver interface to send the signal values to the Com module.
Figure 17: TempSensor (SWC) ) Interaction Diagram

When TempSensor component is in active state it shall constantly read measured Adc value from the IoHwAb
module. It shall do this in a periodic runnables which is scheduled every 10ms.
Runnable Period
TempSensor_Runnable_AC_Main 10ms
TempSensor_Runnable_DC_Main 10ms

10033136 SACID
4.1.2.3.11.3 Control Pilot Evaluation (CPE)
The ControlPilotEvaluation(CPE) software component is responsible of acquiring data such as Voltage,

Frequency and Duty Cycle on the Control Pilot Line, and based on the values send appropriate CAN signals to
the HCP5 module. This may help HCP5 to understand the current state of the EV’s Control Pilot Line, based
on which the charging can be controlled.
The ControlPilotEvaluation SWC use the service provided by the IoHwAb module to read the Voltage,
Frequency and Duty Cycle of the Control Pilot Line.
The ControlPilotEvaluation module communicate with Com module via RTE to send the Voltage, Frequency and
Duty Cycle values on the CAN bus.
Figure 18: CPE (SWC) Interaction Diagram

Runnable Period
ControlPilotEvaluation_Voltage_Runnable 10ms
ControlPilotEvaluation_Frequency_Runnable 10ms
ControlPilotEvaluation_DutyCycle_Runnable 10ms
4.1.2.3.11.4 AVS and VAS
AVS
10033136 SACID
AVS connector locking mechanism detect the status of actuator(plug) locks . AVS module interact with IoHwAb
module to read the actuator status in terms of ADC counts. These Adc counts are converted to resistance to
find the status of actuator . AVS also send the actuator(plug) lock status via CAN bus .
VAS
VAS get the actuator lock status from AVS(via send receiver interface) and the lock/unlock command from
HCP5 via CAN Bus.VAS module apply the lock/unlock command based on the actuator locks status from
VAS.VAS module interact with IoHwAb module to trigger the actuator(plug) lock /unlock command.
Figure 19 : AVS and VAS Interaction Diagram
Runnable Period
AVS_Connector_Locking_Mech_Runnable_Main 10ms
VAS_Locking_Mechanism_Control_Main 10ms
4.1.2.3.11.5 PPE
Proximity module check the presence of different type of plug system (CCS1/Type1 , CCS2/Type 2 , GB/T )
connected . This is done by analyzing the input from proximity pin. Proximity Detection module interact with
IoHwAb component to read the analog value at the proximity pin . And it interact with Com module (send -
receiver interface )to send the Plug detection status on CAN bus.
10033136 SACID
Figure 17 : PPE Interaction Diagram
Runnable Period
PxoximityDetection_Runnable_Main 10ms
4.1.2.3.11.6 LKPE and VALK
LKPE
LKPE module detect the status of flap . LKPE module interact with IoHwAb module to read the actuator(flap
motor ) status in terms of ADC counts. These Adc counts are converted to resistance to find the status of flap .
LKPE also send the flap status via CAN bus .
VALK
VALK get the actuator(flap) lock status from LKPE(via send receiver interface) and the flap lock/unlock
command from HCP via CAN Bus.VALK module apply the flap lock/unlock command based on the actuator
(flap) locks status from LKPE.VALK module interact with IoHwAb module to trigger the flap lock /unlock
command.

10033136 SACID
Figure 20 : LKPE and VALK interaction diagram
Runnable Period
VALK_Control_Locking_Mech_Runnable_Main 10ms
LKPE_Control_Locking_Mech_Runnable_Main 10ms
4.1.2.3.11.7 ISOND
ISOND component receive the EVSE parameters from HCP5 via CAN, encode and send them to EVSE
through PLC communication established. ISOND module also control the state machine of the SCC module
and send the ISO messages accordingly. ISOND module shall implement the callbacks required by the SCC
modules. When this callbacks invoked ISOND shall provide the requested parameters received from HCP5.

10033136 SACID
Figure 21 : ISOND interaction diagram

Runnable Period
ISOND_Runnable_Main 10ms
4.1.2.3.11.8 LED
LED component shall be responsible for the display of search light and charging scenarios in LEDs.
LED component shall control four output PWM interface which are connected to the inlet LEDs.
LED component shall write to the output PWM interface based on the received scenario from HCP5.
LED SWC shall interact with IoHwAb for PWC control and interact with Com module (S/R interface) for receiving
the LED display scenario. See Chapter 3 more details of PWM channel configuration.
Runnable Period
LED_Runnable_Main 10ms
4.1.2.3.11.9 CCDC
CCDC component shall be responsible for the detection of GBT DC connector based on standardized
resistance values with plugged and unplugged connector (GBT DC). CCDC module shall interact with IoHwAb
module to read the following analog input signal value based on the connector status.
1. Plug signal - analog
2. Wakeup counter

10033136 SACID
Based on the connector detection status , CCDC module shall update the following CAN signals transmitted to
HCP5 module.
CAN Signal Direction

CCDC_CC_Status_DC_GBT Tx
CCDC_CC_Latchstatus_DC_GBT Tx
CCDC_CC_Fehlerstatus_DC_GBT Tx
CCDC_WeckAnf_DC_GBT Tx
Runnable Period
CCDC_Runnable_Main 10ms
4.1.2.3.11.10 CDOE
CDOE component shall be responsible for the detection of CHAdeMo connector based on the state of
optoelectronic switch .CDOE module shall interact with the IOHwAb module to read the following Analog input
signals.
1. CSS1
2. CS
Base on the value of these Analog input signals , CDOE module shall update the following CAN signals
transmitted to the HCP5 module.
CDOE_Status Tx
CDOE_Fault_Status Tx
CDOE_WeckAnf Tx
Runnable Period
CDOE_Runnable_Main 10ms
4.1.2.3.11.11 LKAE
LKAE component shall be responsible for the activation of electric flap connected via LIN. This component
shall be active only in software variants with flap connected via LIN. LKAE module receive the flap lock
activation commands from the HCP5 module via CAN communication. LKAE module receive the flap lock from
LKPE module.
Based on this input signal LKAE module shall update the LIN signals.
Following are the input signal received from HCP5 via CAN

10033136 SACID
CAN signal Direction

AVLK_Ladeklappe_VerEntriegeln_Anf Tx
AVLK_LadeklappeAnsteuerungSollMoment_lk1 Tx
AVLK_LadeklappeAnsteuerungSollMoment_lk2 Tx
AVLK_LadeklappeAnsteuerungSollGeschwindigkeit_lk1 Tx
AVLK_LadeklappeAnsteuerungSollGeschwindigkeit_lk2 Tx
Input signal from LKPE

LKPE_LadeklappenPosition_Lk1 Rx
LKPE_LadeklappenPosition_Lk2 Rx
LKAE module shall update the following LIN signals.

LIN Signal Direction
LKAE_Ansteuerungsstatus_Lk1 Tx
LKAE_Ansteuerungsstatus_Lk2 Tx
LKAE_Ladeklappenposition_Lk1 Tx
LKAE_Ladeklappenposition_Lk2 Tx
Runnable Period
LKAE_Runnable_Main 10ms
4.1.2.3.11.12 CDOKS
This module shall controls the communication for Chademo charging and evaluate the HW pins for the
charging sequence. CDOK module shall process the analog input signals CCS1 , CCS2 and CPP of the
CHAdEMO charging interface. This module also shall act as gateway between the CAN communication
between the CHAdEMO charging station and the HCP5.
Input signal from CDOE
CDOE Signal Direction
CDOE_Status Rx
CHAdeMO Input signals(CAN)

CAN signal Direction
CDOP_MinStromFzg Rx
CDOP_MaxSpannungFzg Rx
CDOP_ReferenzLadezustandFzg Rx
CDOP_MaxLadezeitFzg Rx
CDOP_MaxLadezeitFzg_ext Rx
CDOP_GesamtKapazitaet Rx

10033136 SACID
CDOP_ProtokollVersionFzg Rx
CDOP_ZielLadespannungFzg Rx
CDOP_SollAnforderungFzg Rx
CDOP_FehlerHvBatUeberSpannungFzg Rx
CDOP_FehlerHvBatUnterSpannungFzg Rx
CDOP_FehlerHvBatIstStromDiffFzg Rx
CDOP_FehlerHvBatUeberTempFzg Rx
CDOP_FehlerHvBatIstSpannDiffFzg Rx
CDOP_LadebereitFzg Rx
CDOP_WaehlhebelPosFzg Rx
CDOP_FehlerFzg Rx
CDOP_HvBatIstLadezustandFzg Rx
CDOP_CDO_LsNachrichtSendenAnf Rx
CDOP_CDO_LadeerlaubnisFzg Rx

CDOKS_SnMethodeLs Tx
CDOKS_MaxSpannungLs Tx
CDOKS_MaxStromLs Tx
CDOKS_MaxAbschaltSpannungLs Tx
CDOKS_ProtokollVersionLs Tx
CDOKS_IstspannungLs Tx
CDOKS_IststromLs Tx
CDOKS_IstStatusLs Tx
CDOKS_FehlerstatusLs Tx
CDOKS_VerriegelungsstatusLs Tx
CDOKS_Ausgabe_Erlaubt Tx
CDOKS_HvBatt_InkompatibilitaetLs Tx
CDOKS_FehlerstatusFzgLs Tx
CDOKS_StoppLaden_AnfLs Tx
CDOKS_VerbleibRestladezeitLs Tx
CDOKS_ErwVerbleibRestladezeitLs Tx
CDOKS_CDO_LadenStartStop1Ls Tx
CDOKS_CDO_LadenStartStop2Ls Tx

10033136 SACID
CDOKS_LsMsgEmpfangen Tx
CDOKS_Fehlerstatus Tx
Runnable Period
CDOK_Runnable_Main 10ms
4.1.2.3.11.13 GBTSK
This module shall receive the messages which are coming from the GB charging station . The information in
the messages are put on the corresponding signal in CAN-FD communication to HCP5.
And this module also shall assign the signal which are coming from HCP5 module to corresponding Tx
messages to GB charging station.
Following are the input signal from charging station
GBT signals Direction
CHM: Ladesäule Handshake (Charger handshake) Rx
CRM: Erkennung Ladesäule (Charger recognization) Rx
CML: Maximale Leistung der Ladesäule (Charger’s Rx
maximum output capacity)
CRO: Ladebereitschaft der Ladesäule (Charger Rx
output readiness status)
CCS: Ladezustand der Ladesäule (Charger charging Rx
status)
CST: Ladeende der Ladesäule (Charger end-of- Rx
charge)
CSD: Statistik der Ladesäule (Charger statistical Rx
data)
CEM: Timeouterkennung der Ladesäule (Charger Rx
error message)
Input signals from CCDC

Direction
CCDC_CC_Status_DC_GBT Rx
Output signals to the charging station

GBT signals Direction
BHM: Fahrzeug Handshake (Vehicle handshake) Tx

10033136 SACID
BRM: Erkennung Fahrzeug (BMS and the vehicle Tx

recognozation message)
BCP: Ladeparameter der HV-Batterie (Power battery Tx
charging parameters)
BRO: Ladebereitschaft des Fahrzeugs (Battery Tx
charging readiness status)
BCL: Bedarf der HV-Batterie (Battery charging Tx
demand)
BCS: Ladezustand der HV-Batterie (Overall status of Tx
battery charging)
BSM: Status der HV-Batterie (Power battery status Tx
information)
BST: Ladeende des Fahrzeugs (BMS end-of-charge) Tx
BSD: Statistik des Fahrzeugs (BMS statistical data) Tx
BEM: Timeouterkennung des Fahrzeugs (BMS error Tx
message)
Runnable Period
GBTSK_Runnable_Main 10ms
4.1.2.3.11.14 EEBUS_Logic
Data is exchanged according to EEBus standard on the Ethernet interface between SACID and ConMod .
EEBUS_Logic module shall map the data according to EEBUS standard to CAN FD signals(Tx/Rx signal
to/from HCP5).
4.1.2.4 Software Components Responsibilities
Software component responsibilities are documented in the SDP document SDP_10033136_PO10CG .

10033136 SACID
(http://s03.delphiauto.net/17/ConnProj/10033136/Systems/Forms/AllItems.aspx?RootFolder=%2F17%2FConn
Proj%2F10033136%2FSystems%2F10%20Planning%2F30%20Software%20Plans)
4.2 Software Safety Concept
4.2.1 Self-Test
According to the safety goals identified for SACID following features shall be implemented according the safety
level ASIL A.
1. Temperature sensor measurement
2. LED functionality
3. Plug motor lock/unlock feedback
4. Plug motor lock /unlock
5. Plug detection
6. Flap lock /unlock
7. Control Pilot detection.
Following safety measures shall be implemented in the SACID software
4.2.1.1 RAM Test
A requirement of the ISO26262 is to detect the accumulation of latent defects. ST Microcontroller has built in
programmable hardware module called Self-Test Control Unit (STCU2), which provide self-test blocks.. STCU2
manage logic built in Self-Test (LBIST) and SRAM built in Self-Test (MBIST) blocks of the device. MBIST bock
shall be used to detect the fault in the RAM.
MBIST shall be implemented for each of the SRAM contained in the Microcontroller.
MBIST shall be configured to execute(offline mode) the test every time the MCU boots or gets destructive reset.
Offline MBIST test shall be configured using Device Configuration Format (DCF) record that automatically
configure the STCU2 to enable and run the MBIST at startup . DCF records are stored in the UTEST memory .
The DCF records provide an interface that can be used to initialize registers within the selected modules (DCF
clients) during system boot . The STCU2 registers are DCF clients. DCF clients are 32-bit wide hardware
registers inside a module that receive and store the data from a DCF record. This stored data is used to initialize
STCU2 registers and to configure the STCU2 for MBIST during startup. Configuration of the MBIST is loaded
to the STCU2 by the SSCM module during the PHASE 3 of the reset sequence.
STCU2 module will trigger a functional reset after MBIST. There shall not be MBIST test during functional reset.

10033136 SACID
Figure 22: RAM Test (MBIST) sequence

After functional reset MBIST test result shall be checked before application starts. Status of MBIST test can be
checked by reading the status registers of STCU2 and MEMU status registers. Errors shall be reported to the
SysSup module to take further action.
Figure 23 : SysSup Error Handling - RAM Test

10033136 SACID
4.2.1.2 Flash Array Integrity check
To check the integrity of the flash , SACID software shall enable Flash Array integrity check . This can be done
by putting the flash into user test mode. Flash Array integrity check is done before Operating system initialization
in the startup phase.
Flash Array Integrity Check (FAIC) reads data from selected flash blocks and calculates the MISR signature.
This calculated MISR signature will be compared by flash controller (in runtime) with MISR calculated during the
software build and it is included in the s-record file. If the MISR is identical, then the content of selected flash
blocks corresponds to content in s-record file and that there are no ECC errors (single bit or double bit ECC
errors).
During Flash Array integrity check no exception will be reported if double bit ECC errors are detected.
Flash Array integrity check shall be implemented in the SysSup module and it will be executed during startup
phase .
4.2.2 Data Consistency Mechanism
Concurrent accesses to shared data memory can cause data inconsistencies. We have system where several
code entities accessing the same data memory are running in different contexts. Due to this fact Autosar
Recommended Data Consistency Mechanism are considered in the Design of the system. In AUTOSAR
systems the RTE will take care that communication is not corrupted by data consistency problems.
Concept of Exclusive area and InterRunnableVariables are used where RTE guarantee the data consistency
for SW- C communication and execution circumstances. In the case of Basic Software Modules exclusive
areas handled by Basic Software Scheduler(SchM is integrated within RTE) is used.
4.2.2.1 Exclusive Areas
Exclusive Areas are associated with RunnableEntitys .Focus of the Exclusive Area concept is to block potential
concurrent accesses to ensure data consistency. Exclusive Areas implement critical section. The RTE is
forced to guarantee data consistency when the Runnable Entity runs in an Exclusive Area. A Runnable Entity
can run inside one or several Exclusive Areas completely or can enter one or several Exclusive Areas during
their execution for one or several times.
If a critical section shall not be preempted by ISR , exclusive area shall disable the interrupts when enter into the
exclusive area and enable interrupts when exit from the exclusive area. This is done by using the OS functions
SuspendAllInterrupts() and ResumeAllInterrupts()
4.2.3 Safety measure for Communication

4.2.3.1 Inter ECU Communication
End to End protection mechanism shall be implemented to protect against corruption ,repetition , insertion ,
masking and reordering of messages when it is exchanged between SACID and HCP5 via CAN bus.

10033136 SACID
4.2.3.1.1 End-to-End Protection (E2E)
To meet the safety goal it’s important to ensure the integrity of data(safety signal) exchanged between the safety
components and HCP5 via CAN protocol.
All the safety signals exchanged between SACID and HCP5 shall be protected using EndtoEnd (E2E) protection.
Autosar E2E library and E2E Protection Wrapper shall be used to protect the safe data using E2E communication.
Checksum and alive counter are monitored for safe data exchange.
There are safety signals which shall be transmitted from SACD . Such signals shall be protected using E2E
protection mechanism.
E2E Library shall use Profile 2 and Profile 4.
Figure 24: E2E Protection

Following are the safety signal identified . See the data flow diagram in section 5.2 for . Safety signals which
are communicated over CAN bus are marked with red line in the data flow diagram. All these signals shall be
protected using E2E Protection mechanism.
Safety Signal name Direction (Tx/Rx) Name of the component
responsible for using E2E
protection.
Temperature DC Plus/Minus Tx ALST
Temperature AC Tx ALST
Actuator Motor Status Tx VALK
Command to Flap Motor Rx VALK

10033136 SACID
Actuator Motor Status Tx VAS

Unlock Prohibition Tx VAS
ChargingStation Voltage Rx VAS
Emergency Request Rx VAS
Command To Motor Rx VAS
S2SchliessenAnf Rx CPA
CP_Status Tx CPA
CP_Freequency Tx CPA
CP_Voltage Tx CPA
CP_DutyCycle Tx CPA
Proximity Detection Status Tx PPE
PP_FaultStatus Tx PPE
PP_LatchStatus Tx PPE
PP_Max_Storm Tx PPE
CC_Status_DC_GBT Tx CCDC
CC_Latchstatus_DC_GBT Tx CCDC
CC_Fehlerstatus_DC_GBT Tx CCDC
CDOE_Status Tx CDOE
CDOE_Fault_Status Tx CDOE
CDOE_WeckAnf Tx CDOE
Table 12 : Safety CAN Signals
4.2.3.2 Intra Ecu Communication
Communication of safety signal between software components is handled by the safe RTE module (ASIL A
compliant).Safe RTE ensure that there is unintentional repeat , delay insert , mask , corrupt or lose of data
communicated between SWCs.
See the dataflow diagram in section 5.2 to see the safety signal between SW components/IoHwAb.
Safety signal communicated between SW components or to/from IoHwAb are marked in green line.
4.2.4 Memory Partition and Protection

The entire SACID software has not been developed according to the highest ASIL (ASIL A) . But the software
meet specific requirements and support existence of QM level services / modules in parallel with safety related
functions. The key is to have built-in protections to address software issues faced when modules of different
ASIL co-exist. See ISO26262 Part 6, Annex D Freedom of interference between software elements [1]. The
standard lists three areas that need to be addressed to ensure freedom of interference protection namely –
Timing interference, memory access and exchange of information.

10033136 SACID
According to technical safety requirements (TSC [2]) , following components are identified to be ASIL A compliant
to support safety goals for the above mentioned features.
Software Components MCAL BSW

LKPE ADC RTE
ALST DIO Operating system (OS)
AVS PORT WdgM
VAS PWM WdgIf
CCDC WDG (External) IoHwAb
CDOE
CPA
PPE
Table 13 : ASIL Components
Based on the safety classification of SWCs , BSWs and MCALs , software architecture is configured for 2
partitions.
- Trusted Partition (ASIL A components)

- Non-Trusted Partition (QM components)
Allocation of SWCs, BSWs and MCALs to the memory partition is shown in the Figure 25

10033136 SACID
Figure 25 : Software Safety Architecture - Memory Partition
Each partition corresponds to an OS application
Trusted -> Os_Application_Core0_ASIL (Shall be configured to run in Supervisor mode)

Non-Trusted - > OS_Application_Core0_QM (Shall be configured to run in user mode)
Operating system module shall be configured to use memory protection mechanism(SMPU) of the
microcontroller to achieve freedom from interference between the components belongs to trusted and non-
trusted partition. System Memory protection Unit (SMPU) provides memory access control based on the
preprogrammed region descriptors that define the memory region and their access rights.
See below table 14 for the task assignment to the OS application
Task OS application
Core0_Init_Task OS_Application_Core0_QM
Core0_task_Swc_Init_QM OS_Application_Core0_QM
Core0_task_Swc_Init_ASIL OS_Application_Core0_ASIL

10033136 SACID
Core0_Task_BswEthernet_QM OS_Application_Core0_QM
Core0_Task_Bsw_PlcDriver_QM OS_Application_Core0_QM
Core0_Task_BswHighPrio_QM OS_Application_Core0_QM
Core0_Task_BswCrypto_QM OS_Application_Core0_QM
Core0_Task_V2G_QM OS_Application_Core0_QM
Core0_Task_Appl_HighPrio_ASIL OS_Application_Core0_ASIL
Core0_Task_Appl_HighPrio_QM OS_Application_Core0_QM
Core0_Task_Bsw_HighPrio_ASIL OS_Application_Core0_ASIL
Core0_Task_Bsw_LowPrio_QM OS_Application_Core0_QM
Core0_Task_Appl_LowPrio_QM OS_Application_Core0_QM
Core0_Task_Diag_LowPrio_QM OS_Application_Core0_QM
Core0_Task_SysSupervision_QM OS_Application_Core0_QM
Core0_Task_Idle OS_Application_Core0_QM
Table 14 : Task mapping to OS Application.
Region descriptors shall be configured for the following memory regions. This shall be done through the OS
configuration.
Region Access Rights
Trusted Non-Trusted
(Os_Application_Core0_ASIL) (OS_Application_Core0_QM)
Read Write Execute Read Write Execute
Core0_QM_noinit_ram x x x x
Core0_QM_ram_data x x x x
Core0_QM_ram_bss x x x x
Core0_ASIL_ram_data x x
Core0_ASIL_ram_bss x x
Core0_Rte_Ram_noncached x x x x
Core0_QM_code x x x x
Core0_ASIL_code x x
Table 15 : RAM / ROM MPU Regions with access rights.
OS reserves one memory region which is reprogrammed by the OS with each task switch. So any memory
access violation to the stack is captured by the MPU and reported .
4.2.5 Program Flow Monitoring
Program flow monitoring shall be implemented in the SACID software to check the correct execution of software.

10033136 SACID
The focus of this concept is the detection of program flow errors, i.e. a divergence from the valid program
sequence. An incorrect program flow occurs if one or more program instructions are processed either in the
incorrect sequence, not in time or are not even processed at all.
Logical program flow monitoring shall implemented to detect data corruption , process crashes due to invalid
execution of program sequences.
Logical program flow monitoring shall be implemented for all Safety component(See Table 13) runnables.
Autosar WdgM module shall be used for implementing the Logical program flow monitoring .
Following Supervised Entity and check points shall be configured in the WdgM module for the program flow
monitoring .
Supervised Entity CheckPoints Checkpoint trigger location
SE_IohwAb CP1 Entry-> IoHwAb_MainFunction_AnalogIN_TaskThread
SE_IoHwAb CP2 Exit -> IoHwAb_MainFunction_AnalogIN_TaskThread
SE_IoHwAb CP3 Entry-> IoHwAb_MainFunction_DiscreteIN_TaskThread
SE_IoHwAb CP4 Exit -> IoHwAb_MainFunction_DiscreteIN_TaskThread
SE_IoHwAb CP5 Entry -> IoHwAb_MainFunction_DiscreteOUT_TaskThread
SE_IoHwAb CP6 Exit -> IoHwAb_MainFunction_DiscreteOUT_TaskThread
SE_IoHwAb CP7 Entry->IoHwAb_MainFunction_PWMIN_TaskThread
SE_IoHwAb CP8 Exit->IoHwAb_MainFunction_PWMIN_TaskThread
SE_LKPE CP9 Entry_LKPE_Control_Locking_Mech_Runnable_Main
SE_VALK CP10 Entry_VALK_Control_Locking_Mech_Runnable_Main
SE_AVS CP11 Entry_AVS_Connector_Locking_Mech_Runnable_Main
SE_VAS CP12 Entry_VAS_Locking_Mechanism_Main
SE_PP CP13 Entry->ProximityDetection_Runnable_Main
SE_CP CP14 Entry->ControlPilot_Runnable_Main
SE_ALST CP15 Entry-> TempSensor_Runnable_AC_Main
Table 16 : Supervised Entity checkpoints
An external graph as shown in the Figure 26 shall be configured in the WdgM module . And at each check point
of the Supervised entity WdgM_CheckpointReached shall be called to notify WdgM about the entry of checkpoint.

10033136 SACID
Figure 26 : Program flow (Checkpoint Graph)
4.2.6 Alive Supervision

Alive supervision shall be implemented for the runnables of safety components to ensure execution reliability.
Alive supervision shall detect if a runnable start executing too infrequent or too often.
Alive supervision shall be implemented for the following supervised entities.
Supervised Entity Cycle Time Supervision No of Expected

reference cycle Alive indication
IoHwAb_MainFunction_AnalogIN_TaskThread 5ms 10ms 2
IoHwAb_MainFunction_DiscreteIN_TaskThread 5ms 10ms 2
IoHwAb_MainFunction_DiscreteOUT_TaskThread 5ms 10ms 2
IoHwAb_MainFunction_PWMIN_TaskThread 5ms 10ms 2
LKPE_Control_Locking_Mech_Runnable_Main 10ms 10ms 1
VALK_Control_Locking_Mech_Runnable_Main 10ms 10ms 1
AVS_Connector_Locking_Mech_Runnable_Main 10ms 10ms 1
VAS_Locking_Mechanism_Main 10ms 10ms 1
ProximityDetection_Runnable_Main 10ms 10ms 1
ControlPilot_Runnable_Main 10ms 10ms 1
TempSensor_Runnable_AC_Main 10ms 10ms 1
4.2.7 Timing Protection
Timing protection shall be implemented for all the tasks configured in the OS module (see table 19 ). OS
module shall be configured to SC4 to enable the timing protection.
10033136 SACID
Execution budget of each of task needs to be defined . This shall be done based on the analysis of maximum
execution time of task in worst case scenario.
4.2.8 Watchdog
SACID has external watchdog which is part of the System Basic Chip (TLE9262BQXV33).Watch dog manager
combines all Supervised Entity states from program flow monitoring(see section 4.2.5) and alive
supervision(4.2.6) to a global state . If the global state is WDGM_GLOBAL_STATUS_STOPPED then the WdgM
module shall set the trigger condition to “0 -> No trigger “ . When the trigger condition is “No trigger” , watch dog
driver shall not service the watchdog. This will result in the reset of Microcontroller.. As SACID is safety
relevant(ASIL A) external watchdog with window watchdog mechanism shall be used.
MCU is connected to SBC via SPI module.
Below table shows the SBC modes with respective watchdog modes
SBC Mode Watchdog mode Details
INIT Mode Start with Long open window When coming from SBC Init the watchdog timer is
always started with a long open window.
The long open window allows the microcontroller to
run its initialization sequences and then to trigger the
watchdog.
Normal Mode Watchdog is programmable Window watchdog is enabled
Stop mode Watchdog is fixed or OFF
Sleep mode Watchdog is OFF
Restart mode Watchdog is OFF
Table 17: SBC Watch Dog Modes
The watchdog must be triggered inside the open window. A correct watchdog service immediately results in
starting the next closed window. Should the trigger signal meet the closed window or should the watchdog
timer period elapse, then a watchdog reset is created by setting the reset output RO LOW. The SBC switches
to SBC Restart Mode.

10033136 SACID
Figure 27 : Watchdog window
A watch dog time period of (WD_TIMER) 200ms shall be configured. According to this open window for valid
watchdog trigger is as follows.
tWD = 200ms
Start of Open window = tWD *0.72 = 200* 0.72 = 144ms

End of Open window = tWD * 1.20 = 200* 1.20 = 240ms
So the valid watchdog trigger shall happen between 144ms to 240ms. Any watchdog trigger outside this time
window will cause an reset.
4.2.9 Error Management

CDD module System supervision(SysSup) monitors failure in the system.SysSup module shall use the safety
modules FCCU(Fault collection and control unit) , MEMU (Memory Error Management Unit) and CMU (Clock
Monitor Unit) to capture the error from Microcontroller.
Figure 28: Fault Capture and Control.

10033136 SACID
4.2.9.1 ECC error handling
MEMU unit collect and report the error events associated with ECC logic used on
• Local SRAM
• Peripheral System RAM
• FLASH
MEMU unit forward this faults to FCCU module.
To prevent the total failure in-case of ECC error during runtime, an ECC error handling mechanism shall be
implemented.
• In case of a non-correctable ram ecc error , SysSup module overwrites the invalid cell and performs a
reset.
• In case non-correctable flash ecc error , SysSup module performs a reset.
• In case of a non-correctable data flash ecc error , SysSup module recalculate the instruction address,
and the call Fls ECC handler to stop the read process via the FLS module.
Figure 29: ECC Handling
4.2.9.2 Clock Failure Handling
SysSup module shall configure the CMU to detect any failure in the XOSC clock , System clock and monitor
the PLL to check any deviation in the clock which is locked.
CMU shall be programmed to report the failure to the FCCU module. SysSup module shall monitors the FCCU
module for any clock failure . If there is failure reported , then SysSup module shall perform reset to restore the
clocks.
10033136 SACID
4.2.9.3 Register Supervision
Register Supervision shall be implemented in the System Supervision module to ensure that there is no
unintentional modification of the register values.
SysSup shall implement the function the following function
SysSup_RegisterSupervisionCheck Run every 50ms.
A predefine table with the values of registers of the peripherals Adc, Pwm,SIUL , SPI , CGM and SMPU shall
be created.
SYSSUP_RegisterSupervisionTable Store the register values of peripherals Adc,
Pwm,SIUL , SPI , CGM and SMPU
SysSup module shall periodically (50ms) read the values of registers and compare with the value in the
predefined table. If there is register manipulation detected then SysSup module shall try to recover this by
Performing Microcontroller reset.
4.3 Security Concepts

4.3.1 Hardware Security Module (HSM)
SACID software shall implement necessary cyber security mechanism for protection against risks from malicious
actions. SACID software shall support various cryptographic services required according to Automotive
cybersecurity standards. Since each of this cryptographic services include high secured and complex algorithms
which consume considerable amount CPU load, there is a need of a trusted environment for the execution.
Hardware Security Module (Programmable security subsystem ) available in the Microcontroller(ST584C) shall
be used for the creating the trusted environment .HSM provides hardware acceleration for better performance
of cryptographic algorithms. HSM also provides protected storage which shall be used for storage of key and
CMAC.
SACID shall use vHSM solution from Vector for using HSM module of SPC584C. vHSM provides crypto graphical
services running on HSM (separate and secure core of the microcontroller) and make use of the available
hardware accelerators. vHSM ensures that the crypto material is never passed from the secure core on to
application core.

10033136 SACID
Figure 30 : SACID Secure Environment
SACID shall use AUTOSAR Crypto stack to access the cryptographic services .
Following modules are part of the Autosar crypto stack
CSM - Crypto Service Manager
• Provide Cryptographic services
• Configure cryptographic services and algorithm
CryIf - Crypto Interface
• Provide uniform interface for different crypto solutions.
CryDrv(HW) – Crypto Driver Hardware
• Enable Application software and FBL get access to security algorithms and functions provided by the
HSM module.
4.3.2 Secure Boot

Secure Boot check the integrity of bootloader and other logical blocks(Application software, QCA7005
firmware) by means of cryptographic services. This shall prevent the execution of tampered
software .Validation is done by checking the signature of logical blocks.
Secure Boot require different information for verifying the software block(Application software and QCA 7005
firmware) content. These shall be stored in HSM protected memory area.
• 128 Bit secure Boot key
• Address of the software block
• Size of the software block
• CMAC of the software block
In order to reduce the startup time due secure boot , trusted boot method shall be used.
Trusted Boot

10033136 SACID
First stage is checked sequentially – no parallel execution
First checked entity triggers next check and directly starts subsequent entity
Figure 31 : Secure Boot – Trusted boot

10033136 SACID
Figure 32 : Secure Boot
4.3.3 Secured Communication with HCP5

SACID shall implement secured communication with HCP5.
Following two modules shall be used for implementing the secured communication
1. Secuerd OnBoard Communication (SecOc)
2. Sichere Onboard Kommunikation (SOK)
SecOC is an Autosar module supplied by Vector and SOK is a Standard Software module from Porsche.
SOK module provides freshness value for the SecOC module.SecOC module shall call the following SOK
services(call back functions) to get the freshness value for each Pdu.
• SecOC_GetRxFreshnessAuthData
• SecOC_GetTxFreshness
Freshness Value ID shall be passed as argument to identify the Pdu.Hence Freshness value ID must be
configured to be unique for each SecOC Pdu.
SOK module shall also check the validity of each key that is used by the SecOC module. SOK module interact
with VKMS component to check the validity of the Key. This can be done by calling the VKMS function

10033136 SACID
VKMS_IsTypeIdReady for each key. This check shall be done after each startup and each time when keys are
updated by VKMS.
Figure 33: SOK Interaction Diagram
4.3.4 Secured PLC communication
V2G solution use TLS(Transport Layer Security) version 1.2 for secure communication between EVCC and
SECC. This allows to establish an authenticated and encrypted channel between the EVCC and the SECC.
TLS allows for unilateral or mutual authentication. For ISO unilateral authentication will be used, i.e the EVCC
authenticates the SECC. TLS based communication is established by EVCC by sending SECC Discovery
Protocol message along with parameter TLS enabled.
Supported cipher suites TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 and

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.
For SACID to request TLS based communication with EVSE, it shall get an indication from HCP5 whether to
use TLS or not. For transport layer security, EVCC authenticates SECC using SECC Certificate. This is being
achieved by SECC having a private key corresponding to SECC Certificate, and EVCC having V2G Root
Certificate and verifying the certificate chain from the V2G Root Certificate to the SECC Certificate.

10033136 SACID
ISOND
V2G CRYPTO
CSM
Smart Charging
Communication
CRYIF
TCP/IP
XML CryptoDrv
Security Transport Layer
Security
vHSM
Figure 34: Secured PLC communication

4.3.5 Vehicle Key Management System
The VKMS is used to manage and provide cryptographic key material for vehicles. To this end, individual keys
for each electronic control unit (ECU) are generated and then encrypted in a backend so that they can be
added to a vehicle's individual ECUs during production.
On the ECUs, VKMS software takes care of decrypting and storing the added key material and of providing
the right key for various applications(e g: SOK ) in the ECU.

10033136 SACID
ECU
CSM
DCM
VKMS Adapter
Component CRYIF
DEM
Crypto
HSM
VKSM Core Crypto

Component Library Key Storage
Figure 35 : VKMS Interaction
VKMS adapter component is a CDD module provided by Porsche and the VKMS core component is part of the
Vector HSM firmware.
The VKMS core component is responsible for the persistence of the keys. For the purpose of a secure key
handling this component is implemented in the Hardware Security Module (HSM).SOK module use VKMS
service for fetching the key and also check the validity of the Key.
4.3.6 Security Access to Diagnostic services

SACID shall implement a role based access control mechanism. Instead of the Security Access service(UDS
Service 0x27) , the activation is done by using UDS service 0x31 (Routine Control).
Standard software module SFD from Porsche shall be used for implementing the role based access control.
SFD module check and validate the content of unlock or reset tokens encoded as CV certificate. The signature
of the token is checked using the Csm Signature Verify service. If an unlock token is successfully validated , the
SFD unlocks requested role by performing mode request change in BswM.
SFD shall write the content corresponding to a role in non-volatile memory in order to have the previous activated
role unlocked after an ECU restarted.

10033136 SACID
Figure 36: SFD Interactions
4.3.7 Intrusion Detection System (IDSM)
An attack on the SACID leads to security events which are reported by so-called security sensors . IDSM
module in SACID collect this security events (SEV).
IDSM module provide standardized interface for BSWs and application to report security events(SEV).Based
on the configured rules IDSM filters and aggregate the SEV to qualified onboard security events (QSEV). This
QSEV shall be send to send to HCP5 using SomeIp protocol.
The list of QSEV shall be discussed and confirmed with PAG.
Figure 47: Security Events
• BSW Modules and Applications can act as security sensors and report SEV to the IdsM
• The IdsM passes QSEV to the PduR for transmission to the IdsR

10033136 SACID
Figure 47 : IDSM Architecture

4.3.8 JTAG Protection
JTAG access to host core (e200z420n3) and HSM core (e200z420n3) of microcontroller is protected using set
of conditions (JTAG password and device life cycle).Debug interface is fully enabled when device life cycle is in
‘Customer Delivery’.And the debug interface is disabled when the device life cycle is in ‘InField’.
From the device state ‘InField’ , it is possible to change the state only to ‘FailureAnalysis’.
In FauilureAnalysis state , debug interface can be enabled again by writing the JTAG password in the JTAG
password challenge register of JTAGC using the external debug tool. Debug interface will be enabled if this
password match with the password stored in the DCF record in UTEST memory area.

10033136 SACID
In order to move the Device Life cycle from In Field to Failure Analysis, the device need to pass first level of
security. It means the valid unlock certificate from APTIV’s PKI has to be provided to the ECU via diagnostic
service.
In order to generate the unique JTAG password per ECU, the KDF (Key Derivation Function) shall be used
according to the NIST 800-108. The Key Derivation Key will be generated in the APTIV's offline HSM (Key Broker
Server) using random number generator with 256 bits length according to VW Standard 80180-1. The Key
Derivation Key shall be securely stored in the APTIV's HSM (Key Broker Server).
Below is the inputs for Key Derivation Function Inputs

KDF Inputs Description
Key Derivation Key Generated Key
Context FAZIT ID
Label (Purpose) JTAG
4.4 Software Update

4.4.1 Development Phase
During development phase software is updated through JTAG interface.

Tools used: Trace 32 software and Lauterbach debugger.
4.4.2 Bootloader
During manufacturing and after series production software can be updated using bootloader.
SACID use bootloader supplied by Vector . SACID bootloader support software download over CAN-FD.
For the update process Porsche Standard tool PIDT send the software image to the SACID bootloader via
CAN-FD interface.
Figure 37 : Software Update

10033136 SACID
4.4.3 Bootloader updater
Bootloader updater is used for replacing the existing flash Bootloader(FBL) .Bootloader will be download just
like a normal application download and once started , replace the existing bootloader by the new version.
The picture below shows the overview of the bootloader update process.
Bootloader V1.0 Bootloader V1.0 Bootloader V2.0 Bootloader V2.0
Updater Updater
Application Bootloader Bootloader Application
V2.0 V2.0
Initial Download Updater Update Bootloader Re-download application
Figure 38 : Bootloader Update
4.4.4 Interaction between Application and Bootloader.
When there is a Diagnostic request to Switch to Programming mode , application software shall write a pattern
in the no_init ram (Core0_QM_noinit_ram) before performing the reset . no-init ram is not cleared and
initialized during reset.
Pattern : 'P', 'R', 'O', 'G', 'R', 'E', 'Q', 'U'

Location in the no init ram : 0x400A8000
After reset bootloader check for this pattern during startup and if present control will remain in bootloader and
clears this pattern. If no pattern present then bootloader will check for valid application . This is done by
verifying the CMAC of Application (See section 4.4.7 for details)
4.4.5 HSM Updater (vHsmUpdater)
Update of HSM Firmware is done using Flash Bootloader and HsmUpdater (vHsmUpdater).
FBL receive the updated HSM firmware from software Flashing tool (e g: PIDT tool) and request the HSM
firmware for the verification. After successful verification FBL will write the updated HSM firmware and the header
to the Host code flash reserved . FBL initiate the update process by requesting HSMFirmware to start the
HsmUpdater. HsmUpdater then install the update in HsmCode flash.

10033136 SACID
Figure 39 : HSM Firmware update
4.4.6 Update Mechanism of logical blocks in Program (ROM) Memory
Following logical blocks are defined in SACID . See chapter 7 for details of memory location of this logical
blocks.
1. Hardware Configuration Area
2. Bootloader
3. Application software and QCA firmware
4. HSM firmware
See table below for details of update mechanism of each of the above mentioned logical blocks.
Logical Block Update mechanism
Hardware Configuration Area Hardware Configuration Area is OneTime Programmable.
Hardware(ECU) specific values shall be written in this logical
block. And this values shall be written during manufacturing
process by Aptiv Manufacturing team.
Bootloader Bootloader updater can update the bootloader. See section
4.4.3 for details.

10033136 SACID
Application software and QCA firmware Application software and QCA firmware together builds a single
logical blocks and this can be updated via Bootloader.
It’s not possible to update the QCA firmware alone.
HSM firmware HSM firmware can be updated using Flash Bootloader and
HsmUpdater (vHsmUpdater from Vector)
See section 4.4.4 for details of HSMUpdate.
Table 18 : Logical Block Update Mechanism
4.4.7 Flash data security

Flash Data security (FDS) provides the mechanism to guarantee that only a valid software can be downloaded
to SACID ECU. This is achieved by using digital signature for software.
The below image show the signature generation at the diagnostic tool side.
Figure 40 : Signature Generation - Diagnostic Tool

The below image shows the verification of the signed software by the SACID bootloader during software
update.
Figure 41 : Signature Verify – SACID ECU
4.5 System Behavior on the network

10033136 SACID
4.5.1 CAN
• SACID communicate with HCP5 through CAN FD communication .CAN communication

(Microcontroller and CAN transceiver) is qualified CAN FD with 2Mbits/s transmission and payload
longer than 8-bytes.
• SACID is an active node in the CAN network and generate NM messages after it wake up
• During Power ON SACID will start the CAN communication and start sending the NM messages.
And if there are no NM messages received for 2s , CAN communication will be stopped and SACID
goes to sleep state.
• Any message received on SACID can awake the ECU . And if the received message is NM message
the CAN communication will be requested by itself.
• CAN network go to sleep if there are no NM messages from HCP5
• SACID shall be connected to the Tester (Diagnostic) tool via CAN
4.5.2 ETHERNET
• SACID connected to ConMod(Wireless LAN) via Ethernet.

• Data is exchanged according EEBus standard on the Ethernet interface between SACID and ConMod
4.5.3 LIN
• SACID shall be LIN master

• SACID shall support both LIN wake up and sleep.
• SACID shall gateway all the LIN application data to HCP5 and vice versa without losing any data.
• SACID shall initiate initial LIN sequence to communicate with LIN nodes
• SACID shall use frames 60 (0x3c) and 61 (0x3d) to carry diagnostic data(product and supplier ID etc)
Below Table 26 have the LIN signals to be implemented.
Signal Name Direction
LKLe_kein_reversieren Tx
LKLe_Soll_Moment_Niedrig_Hoch Tx
LKLe_Soll_Pos_XIX_LKLe Tx
LKLe_Referenzierung_Anf Tx
ETSA1_ResponseError Rx
ETSA1_Spielschutz Rx
ETSA1_Entriegeln_Anf Rx
ETSA1_defekt Rx
LKS1_ResponseError Rx
LKL_Drehrichtung_Lk1 Rx
LKL_interner_Fehler Rx
LKL_Mechanik_dreht_frei_Lk1 Rx
LKL_Bewegungsstatus_Lk1 Rx
LKL_Ist_Pos_Lk1 Rx
LKL_Init_Referenzierung_nio_Lk1 Rx
LKL_Referenzierung_ok_Lk1 Rx

10033136 SACID
LKL_Mechanik_blockiert_Lk1 Rx
LKL_Ist_Moment_Niedrig_Hoch Rx
LKL_ResponseError_XIX_LKL1s Rx
Table 26 : LIN External Intreface.
4.6 System Interfaces
4.6.1 JTAG Interface
During development phase software flashing and debugging is done using JTAG debugger.
Debug access to both Host core and HSM core is supported via JTAG the interface. Debug access to SACID
ECU through JTAG interface is controlled by Device lifecycle.
4.6.2 XCP
XCP module is used for the measurement of SACID internal parameters. XCP protocol provide access to all
important internal variables , states and error messages of Basic software. This can be used for debugging the
software.
Following can be monitored via XCP protocol

• DataFlow between SWCs
- Inter Runnable Variables
- Send-Receiver ports
- Mode Ports
• All Error messages and Warnings reported by BSW modules to DET
A2L files needed for XCPMaster are generated using Davinci Tools. Measurement tools like CANape or INCA
use this A2L files to read the ECU internal parameters

10033136 SACID
5 Dynamic Architecture
5.1 ECU (SACID Hardware) States
The picture below shows the different states of software and transitions of the states:
Figure 42: SACID ECU States

10033136 SACID
•STARTUP
Initialization of MCAL modules , SBC chip and Basic software modules are done in startup state. Self-test of
RAM is also executed in the startup state. SACID can enter into STARTUP state due to one of the following
wakeup reason.
1. KL_30 is connected
When KL_30(Battery voltage) is connected SBC will provide the 3.3V and 5V to the microcontroller. With
this Microcontroller will be powered ON and enter into the STARTUP state.
2. CAN FD Wakeup
3. Control Pilot Presence
4. Proximity Wakeup
5. Control Pilot duty cycle change
6. Push button activated
7. LIN Wakeup
8. CHAdeMO wakeup
9. GB/T Wakeup
•ACTIVE
SACID enter into ACTIVE after successful initialization and self test.In ACTIVE state following interfaces are
enabled based on the wakeup reason.
1. CAN interfaces
2. Control pilot's interface
3. CHAdeMO interface
4. PLC interface
5. Ethernet interface
6. China DC GB/T
SACID remains in ACTIVE state as long as one of the above interface is in use and network management
messages are received from HCP5.
•SLEEP
SACID enter into SLEEP state when none of the interfaces are in use and no network management messages
are received from HCP5. To meet the very low current consumption requirement the Hardware designed to use
the wake up concepts (including CAN, LIN and General Wake up pin) from SBC instead of micro-controller sleep
mode. SACID enter into sleep state by putting SBC to sleep state .In this mode , VCC1 regulator is OFF and not
supplying the microcontroller anymore. And in this mode CAN and LIN transceiver also enabled as wakeup
capable. These settings are done before SBC enter into sleep state. A wakeup event on one of the CAN or LIN
will return the SBC to normal mode and signal the wake source.
10033136 SACID
•ERROR
SACID enter into ERROR state if there are error during execution of the software.
Following error can trigger SACID to enter into ERROR state.
1. RAM ECC Error
2. Flash ECC Error
3. PLL Clock Deviation (Fault Detected by CMU)
4. MCU Peripheral initialization Error
5. Under/Over voltage detection
There is a sub-state called SAFE is defined in the ERROR state to prevent charging functionality if there are
error detected from Plug Driver or Error detected in the DC temperature. In SAFE state all charging functionalities
are disabled. CAN communication with HCP and Diagnostic communication are enabled in the SAFE state.
Figure 43 : SAFE state

10033136 SACID
SAFE STATE
To prevent a total failure in case of a faulty hardware , a concept of failsafe shall be implemented.
Following are the list of faults identified which can cause SACID to enter into error/safe state.
Microcontroller Internal and HW Faults
• Error in Self-Test
• Fault reported by FCCU
• Clock Error
• RAM/ROM ECC Error
• Memory Access violation detected by MPU
• CAN Communication Failure
• SPI Communication Failure
• Under/Lower Voltage
• On board high temperature
• Fault detected from Register Supervision
• OS Task Time Violation
• Program Flow Violation
• Execution Fault (Detected by Alive supervision)
• SBC Error
• Fault from CP,PP,TempSensor, PlugMotor,Flap motor, Chademo Pins and Gbt Pin
Safety/ Security Faults
• E2E Communication Error

• Secure Communication Error
• Software Authenticity and integrity failure of Application software
Two reset counters (Slow and fast) shall be implemented to count the number of reset occurs due to the above
faults. These counters shall be incremented at startup (after each reset). These counter are stored in no-init
RAM area to avoid the re-initialization during startup after reset.
Failsafe reset counter SLOW shall count the number of reset in a time duration of 1 minute. This failsafe
counter SLOW shall be decremented by 1 each 1 minute.
If the failsafe reset counter SLOW is higher than 10 , then software shall activate the failsafe mode.

10033136 SACID
Failsafe reset counter FAST shall count the number of reset in a time duration of 3 second. This failsafe
counter FAST shall be decremented by 1 each 3 seconds.
If the failsafe reset counter FAST is higher than 3, then software shall activate the failsafe mode.
In case of requested reset, these failsafe counters shall not be incremented.
There are two different type of fault handling based on the type of faults .
1. Microcontroller internal/HW faults and Security authenticity /integrity failure .
Following are the sequence of actions before enter into FAILSAFE state.
1. Set DTC corresponding to the error.
2. Notify to HCP5 via CAN
3. Try to do a recovery of fault by performing the Microcontroller reset.
2. Fault from CP,PP,TempSensor, PlugMotor,Flap motor, Chademo Pins and Gbt Pin and E2E/Secure
Communication Error
Following are the sequence of actions before enter into FAILSAFE state.
1. Set DTC
2. Notify to HCP5 via CAN
3. Stay in Active state
In this case SACID5 itself shall not change the operational state.
Figure 48: Failsafe Handling.

In SAFE state software functionality is limited. Following is the software behavior in SAFE state.

10033136 SACID
• CAN communication with HCP5 is enabled. But there will be no communication to HCP5 if the fault is
related to CAN or Microcontroller internal faults which affects CAN communication.
• Diagnostic Communication is enabled to read DTCs and DIDs.
• All charging communication are deactivated.
• Lock access to keys stored in the secured data flash if the entry to SAFE state is due to software integrity
and Authenticity failure.
A power on reset clear all the failsafe counters and software will exit from the SAFESTATE.

10033136 SACID
5.2 Data Flow

Below is the dataflow diagram shows data exchange between various components of SACID.
Red Line - Safety signal communicated on CAN Bus

Green Line – Safety signals exchanged between SWCs or to/from IoHwAB.
Figure 44 : Data flow

5.3 Scheduler
Scheduler functionality is integrated within the RTE. All the BSW module, MCALs, CDD and Software
components have runnables/APIs which needs to be scheduled periodically. RTE module is responsible to
trigger this runnables based on the events associated with the runnables. Based on the events runnables to task
mapping is done in the RTE configuration. According to this configuration RTE triggers the scheduling of
runnable/APIs.
10033136 SACID
5.4 Task Definition:

5.4.1 Start-up Task
A startup task named Core0_Init_task shall be configured. This task shall get activate during the system startup
once the OS is initialized. This startup task is executed only once. Ecu state manager(EcuM) startup two phase
is executed in this task. In startup two phase Rte and scheduler are started which then activate the alarms and
remaining tasks.
5.4.2 Idle Task(Background Task)
An Idle task(Core0_Task_Idle) shall be configured for CPU load measurement. Runnable of RTM (Runtime
Measurement) module shall be executed in this task. This task shall be executed only when there are no other
task is in execution(only when CPU is idle).Hence this task has lowest priority and it is fully pre-emptible.
5.4.3 Tasks Details
Task Type Period Priority Task Preemptive Stack

Order by OS Size
(Bytes)
Core0_Init_Task Basic , Only 25 1 No 256
Autostart once
Core0_task_Swc_Init_ASIL Basic Only 24 2 No 256
once
Core0_task_Swc_Init_QM Basic Only 23 3 No 256
once
Core0_Task_Bsw_HighPrio_ASIL Basic 5ms 22 4 No 1024
Core0_Task_Appl_HighPrio_ASIL Basic 10ms 21 10 No 512
Core0_Task_BswEthernet_QM Extended 5ms 20 5 Yes 4096
Core0_Task_Bsw_PlcDriver_QM Extended 5ms 19 6 Yes 512
Core0_Task_BswHighPrio_QM Extended 5ms 18 7 Yes 512
Core0_Task_BswCrypto_QM Extended 5ms 17 8 Yes 2048
Core0_Task_V2G_QM Extended 5ms 16 9 Yes 2048
Core0_Task_Appl_HighPrio_QM Basic 10ms 15 11 Yes 1024
Core0_Task_Bsw_LowPrio_QM Extended 10ms 14 12 Yes 512
Core0_Task_Appl_LowPrio_QM Basic 10ms 13 13 Yes 512
Core0_Task_Diag_LowPrio_QM Extended 10ms 12 14 Yes 512
Core0_Task_SysSupervision_QM Basic 100ms 11 15 Yes 512
Core0_Task_Idle Basic Only 1 Yes 256
when
OS is
Idle
* Priority: 1 is low --> 25 is high
Table 19 : OS Tasks

10033136 SACID
5.5 Task Mapping

Task Runnable FUSI Order
Level in
Task
Core0_Init_Task EcuM_StartupTwo QM 1
Core0_task_Swc_Init_ASIL LKPE_Control_Locking_Mech_Runnable_Init ASIL A 1
TempSensor_Runnable_Init ASIL A 2
VAS_Locking_Mechanism_Control_Init ASIL A 3
AVS_Connector_Locking_Mech_Runnable_Init ASIL A 4
PxoximityDetection_Runnable_Init ASIL A 5
ControlPilotEvaluation_Runnable_Init ASIL A 6
CCDC_Runnable_Init ASIL A 7
CDOE_Runnable_Init ASIL A 8
Core0_task_Swc_Init_QM Plcks_Slac_Init QM 1
ISOND_Runnable_Init QM 2
VALK_Control_Locking_Mech_Runnable_Init QM 3
Core0_Task_Bsw_HighPrio_ASIL Spi_MainFunction_Handling ASIL A 1
IoHwAb_MainFunction_Runable ASIL A 2
Wdg_MainFunction ASIL A 3
WdgM_MainFunction ASIL A 4
Core0_Task_Appl_HighPrio_ASIL LKPE_Control_Locking_Mech_Runnable_Main ASIL A 1
AVS_Connector_Locking_Mech_Runnable_Main ASIL A 2
VAS_Locking_Mechanism_Control_Main ASIL A 3
PxoximityDetection_Runnable_Main ASIL A 4
ControlPilotEvaluation_Frequency_Runnable ASIL A 5
ControlPilotEvaluation_DutyCycle_Runnable ASIL A 6
ControlPilotEvaluation_Voltage_Runnable ASIL A 7
TempSensor_Runnable_AC_Main ASIL A 8
TempSensor_Runnable_DC_Main ASIL A 9
CCDC_Runnable_Main ASIL A 10
CDOE_Runnable_Main ASIL A 11
Core0_Task_BswEthernet_QM EthIf_MainFunctionRx QM 1
EthIf_MainFunctionTx QM 2
EthIf_MainFunctionState QM 3
SoAd_MainFunction QM 4
TcpIp_MainFunction QM 5
Core0_Task_Bsw_PlcDriver_QM Eth_30_Ar7000_MainFunction QM 1
EthTrcv_30_Ar7000_MainFunction QM 2
Core0_Task_BswHighPrio_QM Com_MainFunctionRx QM 1
Com_MainFunctionTx QM 2
Com_MainFunctionRouteSignals QM 3
LinIf_MainFunction QM 4
Fls_MainFunction QM 5
Fee_MainFunction QM 6
NvM_MainFunction QM 7
Core0_Task_BswCrypto_QM Crypto_30_MainFunction QM 1
Csm_MainFunction QM 2
Core0_Task_V2G_QM Scc_MainFunction QM 1
vCanCcCdm_MainFunction QM 2
vCanCcGbt_MainFunction QM 3
Tls_MainFunction QM 4

10033136 SACID
Exi_MainFunction QM 5
Core0_Task_Appl_HighPrio_QM Plcks_Slac_SM QM 1
ISOND_Runnable_Main QM 2
VALK_Control_Locking_Mech_Runnable_Main QM 3
Core0_Task_Bsw_LowPrio_QM BswM_MainFunction QM 1
EcuM_MainFunction QM 2
ComM_MainFunction QM 3
CanSM_MainFunction QM 4
LinSM_MainFunction QM 5
EthSM_MainFunction QM 6
CanTp_Mainfunction QM 7
CanNM_MainFunction QM 8
Nm_MainFunction QM 9
Core0_Task_Appl_LowPrio_QM Led_Runnable_Main QM 1
AptivDiagSwc_Runnable_Main QM 2
Core0_Task_Diag_LowPrio_QM Dcm_MainFunction QM 1
Dem_MasterMainFunction QM 2
Dem_SatelliteMainFunction QM 3
Core0_Task_SysSupervision_QM SysSup_MainFunction QM 1
Table 20: Runnable to Task Mappings
5.6 Interrupts
Following peripheral shall use interrupt mechanism for their respective functionality
Interrupt source Priority OS application FuSi Level

Adc Conversion end 2 OS_Application_Core0_ASIL ASIL A
Can Tx/Rx/Busoff 9 OS_Application_Core0_QM QM
Counter System Timer 1 OS_Application_Core0_QM QM
Ethernet Rx/Tx 12 OS_Application_Core0_QM QM
Lin Channel 0 Error 4 OS_Application_Core0_QM QM
Lin Channel 0 Rx 8 OS_Application_Core0_QM QM
Lin Channel 0 Tx 7 OS_Application_Core0_QM QM
Lin Channel 0 Error 3 OS_Application_Core0_QM QM
Lin Channel 0 Rx 6 OS_Application_Core0_QM QM
Lin Channel 0 Tx 5 OS_Application_Core0_QM QM
Emios_1_3 10 OS_Application_Core0_ASIL ASIL
QCA_Ar7000_INT16 11 OS_Application_Core0_QM QM
* Priority: 1 is low --> 12 is high
Table 21 : Interrupts

10033136 SACID
All of the above interrupts are implemented as Category 2 interrupt. That means in this case OS is responsible
for the interrupt handling like stack allocation to interrupt , interrupt priority handling , nesting of interrupt ,
invocation of interrupt service routine etc.
Nesting is disabled for all the interrupts. Hence all the interrupt share the same stack memory.
A stack size of 2048Bytes shall be configured for the interrupts.
5.7 OS Hook Functions

Following Hook functions provided by the OS module shall be used.
5.7.1 Error Hook
ErrorHook shall be used for capturing the error reported from the OS module and this shall be reported to System
Supervision module. And based on the criticality of the error SysSup module shall try to recover the from the
error .
Within the Error Hook function following errors shall be captured and reported to the SysSup module.
OS Error Code Error Description
E_OS_ACCESS Illegal Access
E_OS_CALLEVEL Invalid Calling Context
E_OS_ID Invalid OS Object ID
E_OS_LIMIT Maximum task activation reached
E_OS_NOFUNC OS Object is currently not in use
E_OS_RESOURCE Scheduling requested with already occupied resource
E_OS_STATE OS object is not in correct state to perform the
requested operation
E_OS_MISSINGEND Task terminate without a TerminateTask()
E_OS_STACKFAULT A stack fault is detected
E_OS_PROTECTION_MEMORY A memory access violation occurred
E_OS_PROTECTION_TIME A task /ISR exceeds its execution time budgets.
E_OS_PROTECTION_LOCKED A task/ISR blocks for too long
E_OS_PROTECTION_EXCEPTION A trap occurred
E_OS_INTERFERENCE_DEADLOCK Deadlock situation due to interference
E_OS_CORE Core not available
E_OS_PARAM_POINTER A null pointer was given as an argument
Two Error hook shall be defined , one for each OS Application

10033136 SACID
Error Hook Name OS Application Access Rights

Errorhook_ OS_Application_Core0_QM OS_Application_Core0_QM Non-trusted/ User Mode
Errorhook_ OS_Application_Core0_ASIL OS_Application_Core0_ASIL Trusted / Supervisor Mode
5.7.2 Pre-Task Hook
This hook is called by the operating system before execution of a new task.
This hook shall be used for the measurement of the task execution time using RunTime Measurement
(RTM) module.
PreTaskHook_ OS_Application_Core0_QM OS_Application_Core0_QM
PreTaskHook_ OS_Application_Core0_ASIL OS_Application_Core0_ASIL
Rtm_Start shall be called at the beginning of Pre-Task hook to start the measurement of task corresponding to
the measurement ID.
PreTaskHook_<OSApplication>()
{
TaskId = GetTaskID()
If(TaskId == ‘x’)
Rtm_Start (MeasurementID of Task ‘x’)
}
5.7.3 Post-Task Hook
This hook is called by the operating system after executing the current task.
This hook shall be used for the measurement of task execution using RunTime Measurement
(RTM) module.
PostTaskHook_ OS_Application_Core0_QM OS_Application_Core0_QM
PostTaskHook_ OS_Application_Core0_ASIL OS_Application_Core0_ASIL
Rtm_Stop shall be called at the beginning of Post-Task hook to stop the measurement of task corresponding to
the measurement ID.
PostTaskHook_<OSApplication>()
{
TaskId = GetTaskID()
If(TaskId == ‘x’)
Rtm_Stop (MeasurementID of Task ‘x’)
}

10033136 SACID
5.8 Resource Consumption Estimates for all Components
5.8.1 Memory Estimate
Below is the memory estimation of various components used in the SACID software.
RAM (in KB) ROM (in KB)

Application Bootloader Application Bootloader
Boot loader 20 424
MICROSAR + MCAL 70 550
MICROSAR V2G 70 250
QCA 7005 Firmware secure 60 400
HSM 10 10
Aptiv Applications 10 150
Stack 10
Shared RAM 2 2
EEbus 32 400
SACID 2 - Additional Extract 50
Porsche SSW 140
Total Estimate 204 102 1940 424

Available 320 320 3072
Available Free space 36% 68% 23%
Table 22 : Memory Consumption estimates
5.8.2 CPU Load Estimation
Component Average CPU Load

BSW with System extract integrated for CAN 33%
+ LIN
Ethernet communication (EEbus) 10%
PLC Communication enabled 8%
(V2G Stack , ISOND , PLCKS)
SW Components 7%
(ALST, CPE, AVS, VAS. LKPE,VALK)
Trusted to Non-Trusted Communication 7%
(IOC Communication)
Total CPU Load 65%
Table 27 : CPU Load estimation
5.8.3 CPU Load Measurement
Run Time Measurement (RTM) module provided by Vector shall be used for measuring the CPU load of the
software

10033136 SACID
RTM module measure the following
1. Minimum CPU load
2. Maximum CPU Load
3. Average CPU Load
4. Current CPU Load
RTM module measure the CPU load by monitoring the total time spend in the idle task. An idle task shall be
created by configuring a preemptive task with lowest priority in OS.No other runnable or functions shall be
mapped to this task other than the runnable of RTM module Rtm_CpuLoadMeasurementFunction.
RTM module use Periodic Interrupt Timer (PIT) for the time base to measure the time in ticks.PIT shall be
configured with a resolution of 10000 ticks per 1ms.
CDD module Cdd_CpuLoadMonitor shall periodically read the CPU load values published by the RTM module.
There is DID available in the SACID to read the CPU load. When this DID is requested Diagnostic module shall
read the CPU load values from Cdd_CpuLoadMonitor.
5.9 Variant Handling

See section 2.4 for details of SACID variants.
Single software shall handle all software features according to the Hardware variants.
Variant information is written into the Hardware Configuration Area (Flash memory) during the manufacturing
process. During initialization of software HCAMemAccess module shall read the configured variant from the
Hardware Configuration Area. This shall be done in the early phase of initialization as this needed before BSW
module initialization to select the right configuration .
HCAMemAccess module shall provide interface to read the variant information in required format.
Depends on the variants , features and communication buses are enabled during the initialization of software.
There will two set of system extract for SACID with difference in the communication matrix.
To support two different set of configuration MICROSR Identity Manager (IDM) shall be used.IDM implement
post-build selectable mechanism.
To implement IDM Davinci configurator shall be used. With IDM enabled , both system extract can be added to
the same davinci project and generate a merged configuration source code corresponding to both system
extracts.
During initialization of BSW modules , based on the variants right configuration can be selected using the
interface EcuM_DeterminePbConfiguration()

10033136 SACID
Figure 45 : Variant Handling
5.10 Critical Functional Requirements
5.10.1 Timing Requirements

Following are the critical timing requirements taken into account when designing the architecture.
1. SACID software shall complete initialization and send functionally valid values on CAN bus within
200ms during startup.
2. SACID shall complete all the initialization needed for PLC (QCA firmware download and initialization)
and ready for PLC communication within 9s.
5.10.2 Security Requirement – Isolation
There shall be an isolation between SACID external and internal communication . This isolation must disallow
any software or protocol vulnerabilities to compromise SACID completely. It must disallow the attacker to
access the internal interfaces and must protect SACID from any buffer overflow or memory leakage.
There is currently only one Ethernet stack which is shared between vehicle external communication (V2G-
PLC) and vehicle internal communication. Hence it is not possible to create two separate memory partition for
modules involved in Vehicle external communication and vehicle internal communication.
This has been discussed with Porsche Cyber security team. Based on the detailed discussion with Porsche
and Vector , following solution is proposed and agreed .
The following additional protection measures shall be implemented in the SACID software
1. First Barrier
• Increase the confidence in freedom from interference between modules
10033136 SACID
a. Static Code Analysis
b. Disable unused functionality
• Enable SafeBSW option in the configuration of BSW modules (EthIf, TcpIp,SoAd,Eth,
Csm,Cryf,Crypto)
• Enable development error detection
• Implement mechanism similar to DET check in application
2. Second Barrier
• Prevent code execution from RAM to avoid successful code injection attacks. MPU module shall be
configured prevent code execution from RAM.
• Enable stack protection.

10033136 SACID
6 Memory Map
The memory map and memory budget for the SACID software is distributed as follows:
6.1 Program(ROM) Memory
Start Address End Address Size Component Name

0x00FC0000 0x00FC3FFF 16 KB Hardware Configuration Area
0x00FC4000 0x0103FFFF 496 KB Bootloader
0x01040000 0x010BFFFF 512 KB QCA 7005 Firmware
0x010C0000 0x0133FFFF 2048KB Application software
0x0060C000 0x0060FFFF 16 KB HSM Code
0x00610000 0x0062FFFF 128 KB HSM Code
0x00400000 0x00403FFF 16 KB UTEST Block for Device configuration
6.2 Data Memory

0x00800000 0x0081FFFF 128 KB Data flash
6.3 RAM Memory

0x400A8000 0x400A9FFF 8 KB SYSTEM RAM
0x400AA000 0x400AFFFF 24 KB SYSTEM RAM
0x400B0000 0x400E7FFF 224 KB SYSTEM RAM
0x52820000 0x5282FFFF 64 KB Local RAM
0xA0000000 0xA0007FFF 32 KB HSM RAM
0xA0008000 0xA0009FFF 8 KB HSM Standby RAM
0x00680000 0x00687FFF 32 KB HSM Data flash
Following is the Ram allocation for the Application software.
RAM Symbol Address Range Size

Core0_QM_noinit_ram 0x400A8000 – 0x400A8400 1 KB
Core0_QM_ram_data 0x400A8400 - 0x400A9400 4 KB
Core0_QM_ram_bss 0x400A9400 – 0x400C2400 100 KB
Core0_ASIL_ram_data 0x400C2400 - 0x400C3400 4 KB
Core0_ASIL_ram_bss 0x400C3400 – 0x400CFC00 50 KB
Core0_Rte_Ram_noncached 0x400CFC00 – 0x400D2400 10 KB
Core0_Stack 0x52820000 - 0x52822800 10 KB
Core0_HSM_IPC 0x52822800 - 0x52825000 10 KB
See the attached excel sheet for more details on the memory map.
Memorymap_SACID
_SPC584C_3MBFlash_320KBRam.xlsx

10033136 SACID
6.4 Data storage

Table below have the details of data/Parameters (other than Application software , Bootloader) stored
persistently in the ROM or Data flash memory.
Memory Type of data Size Trigger for read Trigger for Write Integrity
Location check
ROM One Time 224 Read during startup phase Written only once at the CRC is
programmable data bytes of the software and used plant calculated for
for the following. this set of
- VW FAZIT -Identify the variants data and
Identification String -Initialize the Ethernet written in the
communication data flash.
-HW Part Number -Initialize the PLC
communication.
-Spare part number Also read during
diagnostic session when
-HW version corresponding DIDs are
requested.
-MCU MAC address
-QCA MAC address
-APTIV serial number
Data Flash SACID coding 192 During startup phase data Diagnostic DIDs are CRC
parameters for bytes will be read and copied to available to write this
Application components RAM. parameters
Data Flash Dem Admin Data 10 During startup phase data Stored to data flash CRC
bytes will be read and copied to during sleep by
RAM(Buffer handled by NvM_WriteAll
the Dem module)
Data Flash - Dem Status 364 During startup phase data Stored to data flash CRC
- Dem Primary Entry bytes will be read and copied to during sleep only if
- Dem Secondary Entry RAM(Buffer handled by data is changed by
- Aging Data the Dem module) NvM_WriteAll
Data Flash Charging session ID 9 During startup phase During normal CRC
bytes (NvM_ReadAll) data will operation any change
be read and copied to is updated in the RAM
RAM variable variable
Scc_SessionIDNvm Scc_SessionIDNvm .
And the data in the
variable
Scc_SessionIDNvm
stored to the data flash
During sleep by
NvM_WriteAll
Table 23 : Persistent Data Storage

10033136 SACID
6.5 Data buffer
Following RAM buffers are available in the SACID which act as Mirror of data stored in the Data flash.
RAM Buffer Sync between buffer and data flash

SACID Coding parameters During Initial cycle default data will be copied from ROM to RAM
Buffer . In the subsequent cycle during startup phase data will be
copied from Data flash to RAM buffer.
Values of this parameters can be updated using Diagnostic DIDs.
When Updated using DIDs , data will be updated in RAM buffer and
then stored to Data flash.
Dem Admin data During Initial cycle default data will be copied from ROM to RAM
Buffer .
In the subsequent cycle during startup phase(NvM_ReadAll) data
will be copied from Data flash to RAM buffer.
During clear DTC RAM buffer will be updated and stored to the
dataflash.
During sleep(NvM_WriteAll) RAM buffer is stored to the dafaflash.
Dem Status During Initial cycle default data will be copied from ROM to RAM
Dem Primary Entry Buffer .
Dem Secondary Entry In the subsequent cycle during startup phase(NvM_ReadAll) data
Aging Data will be copied from Data flash to RAM buffer.
During clear DTC RAM buffer will be updated and stored to the
dataflash.
During sleep(NvM_WriteAll) RAM buffer is stored to the dafaflash
only if the content is changed.
Charging session ID During Initial cycle default data will be copied from ROM to RAM
Buffer .
In the subsequent cycle during startup phase(NvM_ReadAll) data
will be copied from Data flash to RAM buffer.
During sleep(NvM_WriteAll) RAM buffer is stored to the dafaflash
only if the content is changed. If there is a change in the value , that
will be notified by the vScc module.
Table 24 : Data Buffer

10033136 SACID
7 Configuration and Build Process

7.1 AUTOSAR Configuration Tools
MCAL modules (Mcu, Port , Dio , Adc, Spi ,Pwm ,Gpt,Icu,Wdg) are configured and the corresponding source
code are generated using EB tresos studio.
BSW modules, RTE , OS and V2G modules are configured and the source code are generated using Davinci
Configurator.
Software components description of application SW-C is created using Davinci Developer.
Tool Name Version Supplier
EB Tresos Studio 23.0 ST Micro
Davinci Configurator 5.19 Vector
Davinci Developer 4.3 Vector
Table 25 : Autosar Configuration tools
Figure 46 : MCAL and BSW Configuration Workflow

10033136 SACID
7.2 Compiler and Linker
WindRiver V 5.9.6.4 is used as the compiler and linker
7.3 Build Environment
The Aptiv use the standard Build Environment based on MTSA_MAK. The MTSA_MAK build system is based
on Gnu Make, which is a tool to maintain software rebuilding based on dependency analysis. Dependency
analysis is helpful to only recompile things which need to be recompiled after some files changed (MINIMUM
recompile), and to recompile all files needed to be recompiled (CONSISTENT recompile). Dependency is defined
in rules for input files through a "compilation step" onto output files (i.e. the result of the "compilation step"). That
dependency is maintained based on the time stamp of the input and output files. So whenever the output file
has an older modification time than one of the input files, the "compilation step" of the rule is triggered to update
the output files
8 Standards and Reference Documents

Document / Document / Standard Title
Standard ID Number
DE 280.01 Global SPICE Compliant Process (GSCP)
DE 280.02
DE 280.03
53 AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf (Autosar 4.2.2)
9 Definitions and Acronyms

Note: The GSCP Process Guide offers a glossary of terms referenced in the Global Spice Compliant Process
(GSCP).
Term Definition
ASIL Automotive Safety Integrity Level
AUTOSAR AUTomotive Open System ARchitecture
BSW Basic Software
CAN Controller Area Network
CDD Complex Device Driver
CPU Central Processing Unit
CCS Combine Charging System
CP Control Pilot
DIO Digital Input Output
ECC Error Correcting Code
EVCC Electric Vehicle Communication Controller
EVSE Electric Vehicle Supply Equipment
ECU Electronic Control Unit
EB Elektro Bit

10033136 SACID
Term Definition
FBL Flash Boot Loader
GSCP Global SPICE Compliant Process
GPT General Purpose Timer
HCP High Computing Platform
I/O Input / Output
IDSM Intrusion Detection System Manager
ISR Interrupt Service Routine
MCAL Microcontroller Abstraction Layer
MCU Micro-Controller Unit
LIN Local Interconnect Network
PWM Pulse Width Modulation
PLC Power Line Communication
QSEV Qualified Security Events
RTE Run Time Environment
SWC Software Component
SACID Smart Actuator Charger Interface Device
SECC Supply Equipment Communication Controller
SLAC Signal Level Attenuation Characterization
SysSup System Supervision
SEV Security Events
TLS Transport Layer Security


Sad 10033136 Po10cg

Uploaded by

Copyright:

Available Formats

Sad 10033136 Po10cg

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sad 10033136 Po10cg

Uploaded by

Copyright:

Available Formats

Aptiv Advanced Safety & User Experience

Connectivity & Security

Software Architectural Design (SAD)

10033136 MY2022 Porsche

Confidential – Restricted Aptiv information. Do not disclose.

Review and Approval

Reviewer Title Reviewer Name Approval Date

Approved- Revision 4.2 Page 2 of 99

Revision Revision Date Description / Reason for Revision Author

Approved- Revision 4.2 Page 3 of 99

Revision Revision Date Description / Reason for Revision Author

Approved- Revision 4.2 Page 4 of 99

Approved- Revision 4.2 Page 5 of 99

Approved- Revision 4.2 Page 6 of 99

1 Scope and Project Information

1.1 Intended Audience

1.2 Project Information

Approved- Revision 4.2 Page 7 of 99

2.2 System Hardware Block Diagram

Figure 1 : System Block Diagram

The SACID module contains following main hardware components:

2.3 Software Block Diagram

Figure 2: Software Block Diagram

SACID ECU is responsible for the following

Approved- Revision 4.2 Page 9 of 99

2.4 Variant Information for SACID System

Table 1 : SACID Variant Information

2.5 Carry-over parts from other Projects

2.6 New concepts and Technologies

Following new Technologies/solutions are used in the SACID project.

Approved- Revision 4.2 Page 10 of 99

Resource Name Value Description

PFlash 3MB Non-volatile flash memory for program and constants

DFlash 128kB (4x32k) Non-volatile memory used to emulate EEPROM

RAM 320kB Total SRAM size of all Memory type available

Core 1 PPC Core e200z4 @ 120MHz

CAN Nodes 8 Two CAN sub system each having 4 nodes

Ethernet 1 One Ethernet controller 10/100 Mbps

3.2 Microcontroller peripherals

Approved- Revision 4.2 Page 11 of 99

Approved- Revision 4.2 Page 12 of 99

Variants LIN0 LIN1

• SACID support both LIN wake up and sleep.

Approved- Revision 4.2 Page 13 of 99

3.2.9 Digital IOs

Approved- Revision 4.2 Page 14 of 99

Bootloader , Application Program Flash 3 MB 100K Cycle

3.3 Hardware fallback Strategy

Approved- Revision 4.2 Page 15 of 99

4 Static Architecture Description

4.1.1 Alternate Architecture Evaluation

Autosar architecture is chosen for SACID. This is due to the following

4.1.2 Main software structure

• Hardware configuration Area

Approved- Revision 4.2 Page 16 of 99

Component Name Component Responsible

SCC, TLS, EXI , XMLSecurity , DNS , HTTP

Table 3 : SACID components

Approved- Revision 4.2 Page 17 of 99