DELIVERABLE D3.

4 Standard API
PUBLIC Definition

Henrik Lundkvist (SINTEF)

Quality Assurance: Erik de Visser (VDL)
Project acronym: STASHH

Project title: Standard-Sized Heavy-duty Hydrogen

Project number: 101005934

Call: H2020-JTI-FCH-2020-1

Topic: FCH-01-4-2020

Document date: January 25, 2022

Due date: December 31, 2021

Keywords: Fuel Cell, Fuel Cell Module, CAN bus, Interface, Functional Safety, Protocol

Abstract: This document describes the digital interface for communication between an
electronic control unit in an application system and a fuel cell module. The
standard shall fulfil the requirements from a range of different applications, not
least with respect to functional safety. The communication protocol is primarily
intended for CAN bus, and it reuses messages from the SAE J1939 to be
convenient for integration with existing applications.

Revision History
Date Description Author
2021/Aug/27 First draft of structure with content in few Henrik Lundkvist (SINTEF)
sections Markus Kogler (AVL)
2021/Oct/27 Second draft with updates throughout Henrik Lundkvist (SINTEF)
and initial mapping of signals to J1939
2021/Nov/19 Third draft, adding UDS, J1939 signals for Henrik Lundkvist (SINTEF)
voltage limits and some updates
2021/Dec/06 Fourth draft, adding more safety Henrik Lundkvist (SINTEF)
requirements, communication approach, Markus Kogler (AVL)
updated connector
2021/Dec/19 Complete draft for review. Added new Henrik Lundkvist (SINTEF)
signals, usage examples with message Markus Kogler (AVL)
sequence charts, changed connector
chapter to specify only pinout explicitly,
revisions throughout the document.
2022/Jan/25 Final version taking into account review Henrik Lundkvist (SINTEF)
comments from QA

This project has received funding from the Fuel Cells and Hydrogen 2 Joint Undertaking under Grant Agreement
No 101005934. This Joint Undertaking receives support from the European Union’s Horizon 2020 Research and
Innovation programme, Hydrogen Europe and Hydrogen Europe Research.
Any contents herein reflect solely the authors' view. The FCH 2 JU and the European Commission are not responsible for any use that may be
made of the information herein contained.

Standard API Definition Page 1 of 53

 Table of Contents
1 Abbreviations .................................................................................................................................. 4
2 Introduction..................................................................................................................................... 5
3 Requirements .................................................................................................................................. 6
3.1 Safety and Security .................................................................................................................. 6
3.1.1 Emergency Stop ............................................................................................................... 6
3.1.2 High Voltage Interlock Loop ............................................................................................ 7
3.1.3 Cyber Security.................................................................................................................. 7
3.1.4 Alarms .............................................................................................................................. 8
4 Standards and Architecture........................................................................................................... 10
4.1 CAN Bus ................................................................................................................................. 10
4.2 SAE J1939............................................................................................................................... 10
4.3 Architecture ........................................................................................................................... 10
4.3.1 Multiple FCMs ............................................................................................................... 10
4.3.2 System Boundary ........................................................................................................... 12
5 Diagnostics and Prognostics .......................................................................................................... 14
5.1 Alarms and Warnings ............................................................................................................ 14
5.2 Data Collection During Operations........................................................................................ 14
5.3 Unified Diagnostic Services ................................................................................................... 14
6 Interface Specification ................................................................................................................... 16
6.1 Communication Procedure Approach ................................................................................... 16
6.2 State Machine........................................................................................................................ 16
6.2.1 Idle ................................................................................................................................. 17
6.2.2 Standby .......................................................................................................................... 17
6.2.3 Starting .......................................................................................................................... 17
6.2.4 Running.......................................................................................................................... 17
6.2.5 Stopping......................................................................................................................... 17
6.2.6 Error ............................................................................................................................... 17
6.3 Messages ............................................................................................................................... 18
6.3.1 State Machine Control................................................................................................... 18
6.3.2 State Machine Feedback ............................................................................................... 20
6.3.3 Emergency Stop Request............................................................................................... 22
6.3.4 Reference Power Value ................................................................................................. 24
6.3.5 FCM Actual Current and Voltage ................................................................................... 25

Standard API Definition Page 2 of 53

 6.3.6 Power Limits .................................................................................................................. 26
6.3.7 Voltage Limits ................................................................................................................ 26
6.3.8 High Voltage Bus Information ....................................................................................... 28
6.3.9 FCM Temperature ......................................................................................................... 29
6.3.10 Air Filter Pressure .......................................................................................................... 29
6.3.11 Fuel Information ............................................................................................................ 30
6.3.12 FCM Operating Hours .................................................................................................... 31
6.3.13 Time and Date ............................................................................................................... 31
6.3.14 Ambient Conditions ....................................................................................................... 32
6.3.15 Vehicle Speed ................................................................................................................ 33
6.3.16 FCM Gas Leakage........................................................................................................... 34
6.3.17 Alarm Messages............................................................................................................. 35
6.4 J1939 Signals Summary ......................................................................................................... 37
6.5 Power-up Sequence .............................................................................................................. 38
6.6 Power and State Procedure................................................................................................... 41
6.7 Control of External DC/DC ..................................................................................................... 43
7 Physical Connectors....................................................................................................................... 46
8 Implementation over Ethernet...................................................................................................... 48
9 Conclusion ..................................................................................................................................... 49
10 Appendix: Related Standards .................................................................................................... 50
10.1 Lower Layers .......................................................................................................................... 50
10.1.1 CAN ................................................................................................................................ 50
10.1.2 Ethernet ......................................................................................................................... 51
10.2 Higher Layers ......................................................................................................................... 51
10.2.1 SAE J1939....................................................................................................................... 51
10.3 Diagnostics............................................................................................................................. 52
10.3.1 Unified Diagnostic Services ........................................................................................... 52
10.3.2 Diagnostics over IP ........................................................................................................ 52

Standard API Definition Page 3 of 53

1 Abbreviations

API Application Program Interface

CAN Controller Area Network
CAN-FD Controller Area Network – Flexible Data Rate
CRC Cyclic Redundancy Check
DM1 Diagnostic Message 1
DTC Diagnostic Trouble Code
ECU Electronic Control Unit
FCCU Fuel Cell Control Unit
FCM Fuel Cell Module
HV High Voltage
HVIL High Voltage Interlock Loop
LEL Lowest Explosive Limit
LV Low Voltage
OCV Open Clamp Voltage
OEM Original Equipment Manufacturer
PG / PGN Parameter Group / PG Number
SP / SPN Suspect Parameter / SP Number
UN/ECE United Nations Economic Commission for Europe

Standard API Definition Page 4 of 53

2 Introduction
A standardized fuel cell module has important benefits in terms of economies of scale, market
competition and more efficient system development and operation. To reach a large market, the
standard shall be useful for multiple applications, such as buses, trucks, trains, ships and stationary
generators. However, designing a standard that address the requirements from several markets is
more challenging than a narrower standard targeting a single market. The existing computing and
communication platforms in different industries have to be taken into account, and a compromise
between simple integration into existing applications and a general future-proof solution be found.

The digital interface concept was separated into 3 main topics, as shown in Figure 1. The layering allows
for a reasonable modularity in the solution, such that it will be possible to have a common API that can
interface to different lower layer protocols and connectors. Although it would be possible to start from
a clean sheet and use a broad framework such as OPC UA, this would require significant work for OEMs
to integrate the new standard with their existing systems. Therefore, StasHH takes a pragmatic
approach that we believe will be the most efficient way to reach a market acceptance. We try to
identify existing standards that can be reused and derive practical solutions as modifications and
extensions to those standards. Considering that the truck and bus markets have a potential to drive
the demand for large volumes of fuel cells, it is important to provide a solution that is useful for those
OEMs. Hence, the existing CAN bus and J1939 standards that are very widely used in heavy duty
vehicles has an advantage of providing an easier way to adoption by the truck and bus OEMs. This
document is therefore accompanied by a CAN DBC file that has an accurate description of the signals
in the messages. The DBC format was selected since it is a de facto standard and with multiple tools
available.

The initial goal of the standard was to specify a single connector that would make the FCMs easily
interchangeable. However, it is also considered importance to have a connector with multiple suppliers
to avoid lock-in and problems with availability. Therefore, the standard primarily focuses on the pins
while the specific connector to use is mainly specified in order to have a common connector within the
project during testing.

Figure 1. Layered concept of the digital interface.

Standard API Definition Page 5 of 53

3 Requirements
A mapping of the requirements on the interface has been done based on current implementations of
the partners. The input showed that the level of maturity of the different implementations vary and
that most of the design choices were still open in the sense that there was no strong consensus. A
pragmatic approach is taken where we consider the possibility to adapt the system to the practical
FCM implementation constraints rather than putting too strict requirements on the FCM.

In general, the digital interface is intended to support the basic operation of the FCM. With respect to
the information that needs to be communicated there is therefore a common basis which can be
agreed. The boundaries of the fuel cell module will in most cases include a DC/DC converter to convert
the voltage from the fuel cell stack output to the required voltage of the HV bus.

With respect to the protocols, there is a natural preference to use protocols that are easy to integrate
with existing systems. Due to the difference in existing systems between different sectors, it is difficult
to fulfill all the preferences and a compromise is needed to be able to address a large market.

Due to different power stages of the systems the length of cables and number of FCMs that are needed
in a system to deliver sufficient power can vary. There is a trade-off between the cable length and the
achievable bitrate and latency, hence the standard shall not put higher requirements on the bit rate
than necessary. It was agreed that a bit rate of 500 kb/s should be supported. The standard should not
prevent CAN-FD from being used, although it is not mandatory for the FCM to support CAN-FD.

With respect to the physical connector, it has been agreed that the required ingress protection level is
IP54. It is a preference to use a connector which can be provided by multiple suppliers. The number of
pins and the signals they shall be used for has been analyzed during the specification work, and the
conclusion is that at least 7 mandatory pins should be available and another 7 optional pins are
recommended. In addition, it is recommended to have some additional pins available for proprietary
use and future extensions.

3.1 Safety and Security

Safety and security requirements from different application areas have been identified in StasHH work
package 6. The standard and regulation documents require some interpretation to deduce the actual
impact on the digital interface specification, therefore the most relevant documents for the digital
interface have been reviewed based on the input from WP6. In the following subsections the
conclusions on the requirements for emergency stop, HVIL, cyber security and alarms are summarized
with reference to examples from a subset of the relevant documents.

3.1.1 Emergency Stop

Most applications have a requirement on emergency stop functionality. For electric vehicles there is a
need to fulfil safety criteria to avoid electrical shock in case of a crash, following the UN/ECE regulations
94, 95 and 137 for different types of crashes. The requirements imply that the HV bus shall be de-
energized quickly, hence a fast and robust shutdown procedure shall be implemented in the FCM.

In IEC 62282-3-100 safety standards for stationary fuel cell power systems are defined. Regarding
shutdown the standard states that:

If the fuel cell generator is provided with an integral single emergency stop device, or terminals for
connection for a remote emergency stop device, the circuit shall prevent further power supply export

Standard API Definition Page 6 of 53

in any mode of operation. /…/Plug-connected fuel cell generators do not require an emergency
switching device if the plug can perform the same function.

For maritime applications there is also requirements on supporting emergency shutdown in case of a
certain alarms. In the DNV Rules for Classification it is also stated that signals required for certain safety
functions shall be hardwired.

To support the requirements, our interpretation is that a combination of a hardwired emergency stop
signal and an emergency signal in the communication protocol will provide the necessary robustness.

3.1.2 High Voltage Interlock Loop

To avoid that the FCM is delivering power when it is not connected to the HV bus it is common to use
HVIL which sends a low voltage signal through the HV connectors in a closed loop. When the HV
connectors are not properly closed the LV circuit is broken such that the open HV circuit can be
detected rapidly.

UN/ECE regulation no. 100, amendment related to vehicles with electric power train, includes
requirements on high voltage connectors to protect from electric shock:

• Connectors are allowed to be separated without the use of tools, if they meet one or more of
the following requirements:

• (a) They comply with paragraphs 5.1.1.1 and 5.1.1.2 when separated; or

• (b) They are located underneath the floor and are provided with a locking
mechanism; or

• (c) They are provided with a locking mechanism. Other components, not being part of
the connector, shall be removable only with the use of tools in order to be able to
separate the connector; or

• (d) The voltage of the live parts becomes equal or below 60 V DC or equal or below 30
V AC (rms) within 1 s after the connector is separated.

Although there are multiple ways these could be fulfilled, HVIL is a common solution that is widely
used and the preferred solution that is supported in the standard.

3.1.3 Cyber Security

UN/ECE regulation n° 155, cybersecurity for vehicles, contains a list of threats and mitigations that
should be taken into account in vehicles. The regulation applies to vehicle manufacturers, which in
turn need to consider the security of the components included in the vehicles. It must be avoided that
the FCM opens new weaknesses that threatens the cyber security of the system as a whole. Since the
vehicle manufacturer has the responsibility to maintain the security of the whole system it is preferable
to rely on security mechanisms of the vehicle when possible.

This standard defines the communication between the FCM and the application over a CAN bus. The
security and detection of attacks on the CAN bus is considered primarily as a responsibility of the OEM.
It is mainly the diagnostic functionality that may cause problems for cyber security, since external
entities need to communicate with the FCM. The preferred way to handle security is to only connect
to the application system, where a secure gateway can provide connection to the necessary external

Standard API Definition Page 7 of 53

services with the security implemented by the OEM. This allows each OEM to implement the cyber
security procedures according to its own requirements.

Among the requirements that have relevance for the specification is that cryptographic modules shall
be in line with consensus standards. Since the cryptographic methods are under constant development
it should be determined what the current and future consensus standards are.

For the maritime sector DNV has published requirements in Class Guideline DNVGL-CG-0325 and
requirements in Class Programme DNVGL-CP-0231. The FCM as part of the Power generation supplying
essential and important systems is considered part of the essential and important systems and are
therefore subject to risk assessment and appropriate protection against cyber-attacks. Four different
security levels are defined, where level 1 only protects against casual or coincidental violations, level
2 protection against intentional violations using simple means and low resources, level 3 protection
against sophisticated attacks with moderate resources and moderate motivation while level 4 protects
against violations with sophisticated means, extended resources and high motivation. The risk
assessment shall define which level is appropriate for the FCM, in general it can be expected that level
2 or level 3 are suitable.

The Class Programme DNVGL-CP-0231 is aligned with ISA/IEC 62443. It is a possibility to get type
approval for a component, such as an FCM, which simplifies the process of integrating it into a ship.
However, this requires that software versions are evaluated and approved by DNV. The class program
specifies the requirements on identification and authentication, use control, system integrity, data
confidentiality, restricted data flow, timely response to events, resource availability and specific
systems and applications.

The system integrator shall produce the cyber security design philosophy, which will determine what
security measures are required on the FCM. Under the assumption that the FCM communicates to a
secure gateway on the application and does not have a direct connection to external networks the
application system can handle the authentication and access control and keep the FCM complexity for
the security functions limited, analogous to the requirements for vehicles.

3.1.4 Alarms
For the maritime sector the requirements on alarms differ from the land-based applications. In DNV's
RULES FOR CLASSIFICATION (part 6 – chapter 2 – section 3), for vessels with fuel cell power installations
onboard there is a requirement for hardwired signals to support alarms in case of:

• Liquid inside fuel cell space

• 40% LEL (lowest explosive limit) inside fuel cell space
• Gas detection in secondary enclosure of pipes
• Loss of ventilation or loss of negative pressure in a fuel cell space
• Loss of ventilation in secondary enclosure of pipes
• Fire detection
• Emergency release button

Our assumption is that the detection of all these can be made outside of the FCM, hence this would
not require additional hardwired alarms in the connector from the FCM.

Standard API Definition Page 8 of 53

The rule proposal 2021-ENG007 from Lloyds Register also requires an alarm in case of a high
differential pressure at a filter that can cause a failure of the fuel cell system. In addition, the flow,
temperature and pressure of the fuel and the oxidant shall be monitored. The same rule proposal also
require that the alarm control and safety systems function as independently as possible from each
other, and the safety related parts of the fuel cell control system shall be independent from the other
control and monitoring systems or comply with safety standards. By relying on safety systems external
to the FCM when possible, a higher degree of independence is achieved. However, the interface
includes messages that can be used to cover these requirements in case the FCM has the
corresponding sensors internally.

For other applications the requirements on alarms and warnings are less detailed, but there is a
requirement for a warning in case of hydrogen concentration exceeding 3,0% volume in air within a
vehicle in UN/ECE Regulation 134. It is worth noting that this differs from the 40% of LEL that is used
as threshold in ships. Hence, the definitions in the specification may need to leave out specific limits
and allow for different settings for FCMs that are used in different applications.

Alarms for gas leakage and temperature deviations are supported in the digital interface, in addition
to the possibility to generate alarms related to other operational parameters.

Standard API Definition Page 9 of 53

4 Standards and Architecture
In this chapter the standards that are used as basis for the StasHH digital interface are listed with the
selected features. For the case where multiple FCMs are used in the same application a hierarchy with
primary and secondary FCMs is described. A brief review of these and additional related standards
can be found in Appendix A.

4.1 CAN Bus

The choice of standards has been made based on their existing support for the required functionality
and the expected potential to reach a large market. For the lower layers of the protocol stack CAN bus
is seen as the best candidate. This is mainly due to the popularity in the automotive sector, which is a
key market for FCMs. The feasibility of using CAN bus is also warranted by the fact that multiple
partners are already using it for control of FCMs.

The StasHH standard does not require CAN-FD to be used, but the intention is to fully support CAN-FD
as an option. With CAN-FD a higher data rate is supported, which minimizes the concerns for
bottlenecks and limitations in the size of the system.

4.2 SAE J1939

For the higher layers SAE J1939 also has a strong position in the heavy-duty market. The standard
includes a large number of signals defined for communication within a vehicle, including hybrid
vehicles. However, fuel cell vehicles have not been explicitly addressed in the standard in a
comprehensive way. Therefore, it is necessary to make sure that all the required functionality can be
supported and add the missing pieces.

The fuel cell module will mainly be controlled in an analogous way as a motor/generator set, which is
well-defined in J1939.

4.3 Architecture
There are two main considerations with regards to the architecture, how to connect multiple FCMs to
an application ECU and inclusion of the DC/DC converter within the FCM.

4.3.1 Multiple FCMs

The first architectural question is how to connect multiple FCMs to the same application system. Then
the power requests need to be divided over the different FCMs to implement an energy management
strategy and the states for the FCMs shall be controlled accordingly. The alarms and warnings also
need to be handled from all the FCMs.

If there is a single FCM on a CAN bus the system will appear as a single FCM system from the FCM point
of view, but to avoid multiple CAN buses from the application ECU a first approach is to connect
multiple FCMs over the same CAN bus as shown in Figure 2.

Standard API Definition Page 10 of 53

 Figure 2. FCMs on a shared CAN bus.

This solution is straightforward from the FCM point of view, while the application ECU needs to handle
the complexity of managing multiple FCMs. A large number of FCMs on the same CAN bus can also
cause challenges with high load on the bus, in particular if the same CAN bus is used for other
components, e.g. the battery or the fuel tank. For each FCM on the bus the load is in the order of 50
kb/s, with most of the data coming from mandatory signals and only a few kb/s is expected to be added
by alarms and optional signals. For each of the FCMs an address shall be provided. Since there is no
source address reserved specifically for FCMs in the J1939 address allocation, addresses from the
dynamic allocation range can be used. For on-highway equipment the range of addresses for dynamic
assignment contains 28 addresses (from 128 to 155). If there are not too many other devices
connected to the CAN bus this leaves room for several FCMs.

To reduce the complexity of the application ECU it is often preferred to have one of the FCMs serving
as a gateway that manages the other FCMs. The StasHH interface supports a topology where one FCM
serves as a primary FCM that connects to the application ECU and manages other secondary FCMs, as
illustrated in Figure 3.

Figure 3 Primary - secondary configuration of FCMs.

Standard API Definition Page 11 of 53

The approach is to use the same StasHH standard for the interface between the application ECU and
the primary FCCU as between the primary and the secondary FCCUs. The primary FCM is then
responsible for providing setpoints to the different secondary FCMs to share the load according to
some strategy. The load on the CAN bus between the application ECU and the primary FCU is limited,
and the CAN bus can be used also for other devices. On the CAN bus between the primary and the
secondary FCMs the busload increases by approximately 50 kb/s for each secondary FCMs. The
implementation of the control functionality in the primary FCM is not specified in this standard. It is
not expected that the secondary CAN bus will be used for other devices than the FCMs. The full
dynamic address range is therefore available for the FCMs, and there should not be any problem of
increasing the number of secondary FCMs.

In principle it is possible to use the same CAN bus between the application ECU and the primary FCCU,
and between the primary and secondary FCCUs. However, in this case all the messages to the
secondary FCCUs would be sent first to the primary FCCU which acts as a gateway and then from the
primary to the secondary FCCU. It is therefore not recommended since the bus load would be high.
The connector has the option to include both the primary CAN bus and the secondary CAN bus, which
makes it possible to connect the primary and secondary FCMs with daisy chain cabling.

4.3.2 System Boundary

First the system boundary of the FCM needs to be defined. In many applications it is preferred to have
the DC/DC converter included in the FCM, while in some applications it is preferred to have an external
DC/DC converter. In the first case the DC/DC converter will be controlled by the FCCU, and there is
limited impact on the digital interface. In case of an external DC/DC converter, the DC/DC needs to be
controlled both in terms of the basic operations, such as power limits, management of states and
alarms, and in terms of providing an updated setpoint in order to draw the right amount of current
from the FCM.

From the perspective of the digital interface the DC/DC converter is considered as part of the FCM, as
illustrated in Figure 4. This does not require that the DC/DC is physically integrated into the FCM, but
in case it is not integrated the FCM will be able to control the DC/DC.

The interface between the FCM and the external DC/DC ECU will be the same as between the
application ECU and FCCU. Hence, the external DC/DC converters that will be used in this configuration
will need to support the standard specified in this document. This means that it will be modelled as a
generator/motor set rather than a DC/DC converter. Although there are parameter groups defined in
J1939 for DC/DC converter, they lack the possibility to set a current setpoint. When the DC/DC is
drawing current from the FCM a current setpoint is necessary, therefore the motor/generator
parameters are the preferred alternative.

Standard API Definition Page 12 of 53

 Figure 4. The FCM includes the DC/DC converter from a logical perspective.

Standard API Definition Page 13 of 53

5 Diagnostics and Prognostics
This section gives an overview over diagnostic and prognostic concepts and functions. As a general
principle, the application system will serve as an intermediary for the collection of data for offline
diagnostic and prognostic functions. Hence, all the information that is provided from the FCM to the
application ECU is in principle possible for the application system to provide to cloud based diagnostic
and prognostic functions.

5.1 Alarms and Warnings

The basic diagnostics provided through alarms and warnings are aligned with the principles used in
J1939 Diagnostic Message 1 (DM1). This enables a smooth integration with automotive systems and is
a proven solution that can be reused.

The principle of DM1 is that when there is any active alarm an active trouble code for that alarm will
be included in the DM1 message. The Diagnostic Trouble Code (DTC) contains an identifier of the
failure mode, a 5 bit field, i.e. 32 different failure modes. The SPN is used as the mechanism to identify
the object of the fault. To make the solution easily portable this mechanism is proposed to be used in
the standard also in case it is implemented over e.g. Ethernet instead of CAN bus.

5.2 Data Collection During Operations

For diagnostic and prognostic procedures where additional operation information shall be collected
the cybersecurity can be a challenge. To minimize the new attack surface introduced by the FCM the
information will be provided through the application system.

Although there are many possibilities to collect data and implement diagnostic procedures, the need
for standardized procedures and information is more limited due to the dependence on the internal
implementation of the FCM. The standard is limited to a few parameters that have been identified as
the most useful.

5.3 Unified Diagnostic Services

For service in workshops and for on-demand control of diagnostic information the UDS protocol is
used. The FCCU should support a subset of the possible services that are available in UDS, as listed in
Table 1 and described here.

UDS should be used for reading and clearing stored diagnostic fault codes. This should be a
complement to J1939 DM1, by allowing stored DTCs to be collected. The DTCs to be used are defined
by the respective FCM manufacturers. It is recommended to use the DM1 DTCs in the DM1 format. An
alternative is to have a mapping between the J1939 DTCs and the DTCs used in UDS.

Data transmission read service should be supported to read serial number and software version.

Request Download and Transfer data services should be supported for updating of SW. In addition, the
control DTC setting should be supported to disable error detection during SW updates.

Remote Activation of Routine may be supported for starting and stopping of diagnostic controls or
service procedures.

Security is supported either with security access or with authentication. The diagnostic session control
shall also be supported as a part of the security solution. It is recommended to use appropriate security

Standard API Definition Page 14 of 53

levels for the application with separation of security levels for roles and use cases. Due to the
differences in use cases, with possible implementation of UDS clients in workshops and vehicle
gateways, as well as applications that may not have connection to the Internet both the requirements
and the practical limitations imply that there is no single solution that fits all use cases. Hence, it is left
to the OEM to define the security strategy and the FCM implementation needs to support the required
functionality.
Table 1. UDS services supported by the StasHH standard.

Service Request SID Response SID Comment

Diagnostic Session 0x10 0x50
Control
Security Access 0x27 0x67 Symmetric cryptography
Authentication 0x29 0x69 With asymmetric encryption
Control DTC Setting 0x85 0xC5 To disable error detection, e.g.
during SW updates.
Read DTC information 0x19 0x59

Clear DTCs 0x14 0x54

Read data by ID 0x22 0x62 DID = 0xF180 SW identification
DID = 0xF18C serial number
Write data by ID 0x2E 0x6E

Request Download 0x34 0x74

Transfer Data 0x36 0x76
Request Transfer Exit 0x37 0x67
Routine control 0x31 0x71 For activation of test procedures

Standard API Definition Page 15 of 53

6 Interface Specification
In the following specification we will refer to VCU and application ECU interchangeably, although the
controlling ECU may be called something else than VCU in some applications. The chapter contains an
overview to put the protocol into context, a description of the state machine, specification of the
signals and usage examples.

6.1 Communication Procedure Approach

The main task of the FCM is to supply the power requested by the VCU. The VCU will execute an energy
management strategy for the operation of the HV battery and the FCM.

The main idea behind the following required signals is given by an example of a simplified powertrain
strategy for an electric road vehicle:

First, the driver requests torque for constant driving or acceleration by controlling the acceleration
pedal. The VCU calculates the required power demand for the E-drive. Based on actual state of charge
of the HV battery, the operation state of the FCM and other environmental conditions, the energy
management will split the power demand between battery and FCS. The VCU will send a power request
to the FCM and send a power setpoint to the electric-drive system, the power gap is covered by the
HV battery. For immediate torque, first the power will be provided by the HV battery, until the FCM
power output has ramped up to supply it and even charge the battery.

Power_HV_Battery = Power_E-drive - Power_FCM

Example 1: Example 2:

Power_E-drive = 100kW Power_E-drive = 50kW

Power_FCM = 70kW Power_FCM = 70kW

-> Power_HV_Battery = 30kW -> HV battery is -> Power_HV_Battery = -20kW -> HV battery is
discharging charging

The VCU is aware of the amount and the status of the connected FCMs by evaluation of the alive
counters and by monitoring the state feedback and diagnostic signals from the primary FCCU.

If power for the E-drive is required, the VCU's energy management or the primary FCCU has to decide
to e.g. run one system at full load, or split it between 2 FCMs at half load. Therefore, the state requests
are required to start the FCMs.

6.2 State Machine

A state machine for the main states of the FCM is shown in Figure 5. It should be possible for a FCM
manufacturer to define proprietary substates to these main states. The properties of the different
states are described in this section.

Standard API Definition Page 16 of 53

6.2.1 Idle
In the Idle state the FCM has LV voltage power such that the FCCU is active. This state corresponds to
the "Power on" state in J1939.

Periodic counter messages are transmitted.

6.2.2 Standby
In the standby state the FCM does not output power on the HV interface yet but the necessary
subsystems are powered and ready such that it can start producing output within a short time.

Error and diagnostic messages can be sent.

6.2.3 Starting
The FCM is transitioning from the standby state to the running state. During this state the delivered
power is ramping up, and therefore the power level is not well-defined. The HV bus is enabled and the
module can consume and provide energy.

6.2.4 Running
The FCM is active and delivering power.

The power may be limited due to derating which will be indicated by the FCM.

6.2.5 Stopping
The FCM is ramping down power delivery and returning to standby state.

The HV bus must be enabled during shut-down routines. The output power is not well-defined.

6.2.6 Error
The error state can be entered from any other state.

The FCM should be brought to a safe state.

Standard API Definition Page 17 of 53

 Figure 5. State machine of the FCM.

6.3 Messages
This section lists the messages that are used in the communication between the application ECU and
the FCCU, both with a generic description and a mapping to a J1939 message. The version of J1939
used for the standard is the March 2021 edition.

In general, the reliability of the communication will be protected with message sequence numbers and
cyclic redundancy check (CRC) codes.

6.3.1 State Machine Control

Direction: From VCU to FCCU

The state of the FCM is controlled by requests from the application ECU. The specification gives a basis
with main operation states but depending on the FCM there may be further substates than the main
states in Figure 5. Additional substates will make it possible to support more specific energy
management strategies, for example to handle cold starts.

An FCM state request message will be sent from the application ECU to the FCCU with a request for a
new state. The possible state parameters are the ones indicated from the state machine:

• Standby request

Standard API Definition Page 18 of 53

 o The standby state can be entered either from the idle state or the running state (via
stopping state). The request does not require any additional parameters.
• Start request
o The start request will change the state to running via the starting state. The FCM needs
to have a setpoint for the power or current. The request shall indicate whether power
or current setpoint is used.
• Stop request
o The stop request will change the state to idle. If the initial state is standby the FCM
can transition directly to the idle state. If the stop request is received in the running
state, the FCM will transition to idle via the stopping state.
• Power down
o The power down request will shut down the FCCU and the FCCU will not respond to
any additional messages. If the power down request is sent while the FCM is in the
running state, it will first transition to stopping state and idle state.

The message will therefore contain the requested state and the setpoint for the voltage or current
delivery.

6.3.1.1 Mapping to SAE J1939

The state request message is implemented using the Motor/Generator 1 Inverter Control parameter
group in J1939. Further details of the signal definition may be found in the J1939 Digital Annex 1. The
cycle time of the message is 10 ms.
Table 2. Parameter group Motor/Generator 1 Inverter Control {MG1IC}}, the grey elements are part of the reused J1939 PG
but are not used in the FCM standard.

PGN PG label SPN SP label Scaling Range Length

9728 MG1IC 10157 CRC 1 count per 0 to 255 1 byte
bit count
9728 MG1IC 10158 Counter 16 states 0 to 15 4 bits
9728 MG1IC 10159 Limits 16 states 0 to 15 4 bits
Request
9728 MG1IC 10160 Limits 0.062 5 % per -125 to 12 bits
Request bit 125.937 5 %
9728 MG1IC 10161 Limits 0.062 5 % per -125 to 12 bits
Request bit 125.937 5 %
9728 MG1IC 10162 Setpoint 32 states 0 to 31 5 bits
mode
9728 MG1IC 10163 Setpoint 0.003 906 25 -125 to 2 bytes
request % per bit 125.996 093
75 %

1
The SAE J1939 Digital Annex from March 2021 has been used for the parameters in this standard. Additional
details may be found in J1939/21, J1939/71 and J1939/73.

Standard API Definition Page 19 of 53

Description of the parameters used in the standard:

CRC – SPN10157: 8 bit CRC calculated over the data, source address and PGN. The definition from SAE
J1939 is used. 2

Counter – SPN 10158: 4 bit counter that counts from 0 to 15 and then restarts. This is used for detection
of repeated frames.

Mode Request – SPN 10162: 5 bits field that specifies possible modes, the standard state requests
supported in this standard are:

Power on request: Value = 0 – Power On

Standby request: Value = 2 – Standby

Start request:

• Value = 9 - Enable DC Side Voltage Control Mode – In this mode Control Setpoint
Request is the DC Side Voltage Setpoint in %. Refer to SPN 10203 [Reference Voltage]
to convert % to V.

Value = 10 - Enable DC Side Current Control Mode (w/o DC/DC) – In this mode Control
Setpoint Request is the DC Side Current Setpoint in %. Refer to SPN 10202 [Reference
Current] to convert % to A.

Value = 11 - Enable DC Power Control Mode - In this mode Control Setpoint Request is
the DC Side Power Setpoint in %. Refer to SPN 10172 [Reference Power] to convert %
to kW.

Stop request: Value = 20

Power down: Value = 21 – Power down

Set point Request – SPN10163

• in % of reference value, with the mode selected in SPN 10162, i.e. the reference will
either be in Volt (mode 9), Ampere (mode 10) or kW (mode 11).

6.3.2 State Machine Feedback

Direction: From FCCU to VCU

The FCCU reports the current state to the application ECU using this message. In addition to the state
of the FCM the state of the HVIL is essential for the operation of the FCM since it is necessary to have
the HV connected in the standby and running states. Therefore, the HVIL status is also included in the
state feedback.

The information included in the message are the FCM state and the HVIL status. In case HVIL is not
used the FCM can signal "N/A".

2
The CRC is defined as follows: Length: 8 bits; Polynomial: x^8+x^5+x^3+x^2+x+1; Initial Value: FFh; Input Data
Reflection: Not reflected; Result Data Reflection: Not reflected; XOR value: FFh.

Standard API Definition Page 20 of 53

6.3.2.1 Mapping to SAE J1939
The state feedback is signaled using the Motor/Generator Inverter mode which is aligned with the
mode used for the control of the FCM. The cycle time of the message is 100 ms.
Table 3. Motor/Generator 1 Inverter Mode FB {MG1IMF1}, the grey elements are part of the reused J1939 PG but are not used
in the FCM standard.

PGN PG label SPN SP label Scaling Range Length

61825 MG1IMF1 10164 CRC 1 count per 0 to 255 1 byte
bit count
61825 MG1IMF1 10165 Counter 16 states 0 to 15 4 bits
61825 MG1IMF1 10166 Limits 16 states 0 to 15 4 bits
Request
61825 MG1IMF1 10167 FCM 32 states 0 to 31 5 bits
State
61825 MG1IMF1 9103 HVIL 4 states 0 to 3 2 bits
status

FCM states

0 = Powered On / Idle state - the inverter is commanded to be powered on and able to communicate,
but the Power Stage is disabled e.g. no switching or output.

2 = Standby - the inverter Power Stage is powered but commanded to a neutral operating mode.

9 = DC Side Voltage Mode

10 = DC Side Current Mode

11 = DC Power Control Mode

18 = Starting state, the FCM is starting to deliver power on the HV bus.

20 = Stopping state (active discharge mode. The feedback mode may transition to Mode 0 – Idle state
once capacitance is discharged.)

30 = Error

SPN 9103 – Inverter HVIL status

Reports the High Voltage Interlock Loop (HVIL) state.

00b = HVIL Closed

01b = HVIL Open

10b = Error

11b = Not Available

Standard API Definition Page 21 of 53

6.3.3 Emergency Stop Request
Direction: From VCU to FCCU

Command to shut down this High Voltage Energy Storage Pack instance. A normal power-down may
involve steps that take some time (tests, writing of data, etc.). However, an emergency power-down
should shut down the storage system as quickly as possible, for example in the event of a vehicle
accident. The FCM should always support the command to execute emergency power-down, even if
the actual power-down process is the same as that used during a "normal" power-down.

6.3.3.1 Mapping to SAE J1939

The emergency stop request is implemented through the High Voltage Energy Storage System Control
1 parameter group. This parameter group includes a power-down command with the option of an
emergency power down where the normal procedure is too slow. The transmission interval for the
parameter group is 20ms.

Standard API Definition Page 22 of 53

Table 4. Emergency/Handshake {HVESSC1}.

PGN PG label SPN SP label Scaling Range Length

6912 HVESSC1 8123 Connect 4 states 0 to 3 2 bits
Command
6912 HVESSC1 8124 Power-Down 4 states 0 to 3 2 bits
Command
6912 HVESSC1 8125 Active 4 states 0 to 3 2 bits
Isolation
Test
Command
6912 HVESSC1 8126 Passive 4 states 0 to 3 2 bits
Isolation
Test
Command
6912 HVESSC1 8127 Cell 4 states 0 to 3 2 bits
Balancing
Command
6912 HVESSC1 8213 Enable 4 states 0 to 3 2 bits
Internal
Charger
Command
6912 HVESSC1 8412 Operation 4 states 0 to 3 2 bits
Consent
6912 HVESSC1 8433 High Side 4 states 0 to 3 2 bits
Resistor
Connect
Request
6912 HVESSC1 8434 Low Side 4 states 0 to 3 2 bits
Resistor
Connect
Request
6912 HVESSC1 20878 Thermal 4 states 0 to 3 2 bits
Management
Maintenance
Request
6912 HVESSC1 13027 Control 1 16 states 0 to 15 4 bits
Counter
6912 HVESSC1 13028 Control 1 1 count per 0 to 255 1 byte
CRC bit count

E-Stop – SPN 8124, values:

00b = Power-down not requested

01b = Execute normal power-down

10b = Execute emergency power-down

11b = Don't care/Take no action

The FCM should always support parameter value 10b, even if the actual power-down process is the
same as a normal power-down.

Standard API Definition Page 23 of 53

6.3.4 Reference Power Value
Direction: From FCCU to VCU (in case from FCCU to external DC/DC)

The setpoints for the power, voltage or current from VCU to FCCU are provided using percentage
values relative to a reference. The reference values are provided by the FCCU to the application ECU
in kW, Volt or Ampere. The FCM shall provide updated reference values according to the state of health
and operating condition.

These values can also be used as set point values for the external DC/DC converter. As
source/destination addresses differ, also sharing the same CAN bus is possible. Depending on the
DC/DC operational mode, there will be a current set point (galvanostatic control) or a voltage setpoint
(potentiostatic control).

6.3.4.1 Mapping to SAE J1939

Motor/Generator 1 Inverter Reference 2 is used to provide the reference values for current and
voltage.
Motor/Generator 1 Inverter Reference 1 is used to transmit the reference value for the power. The
transmission interval is one second for both of the parameter groups.

Table 5. Motor/Generator 1 Inverter Reference 2.

PGN PG label SPN SP label Scaling Range Length

64371 MG1IR2 10200 CRC 1 count per 0 to 255 1 byte
bit count
64371 MG1IR2 10201 Counter 16 states 0 to 15 4 bits
64371 MG1IR2 10202 Reference 0.125 A per 0 to 8 2 bytes
Current bit 031.875 A
64371 MG1IR2 10203 Reference 0.125 V per 0 to 8 2 bytes
Voltage bit 031.875 V

Table 6. Motor/Generator 1 Inverter Reference 1.

PGN PG label SPN SP label Scaling Range Length

64373 MG1IR1 10168 CRC 1 count per bit 0 to 255 1 byte
count
64373 MG1IR1 10169 Counter 16 states 0 to 15 4 bits
64373 MG1IR1 10170 Reference 0.5 Nm per bit 0 to 32 127.5 2 bytes
Torque Nm
64373 MG1IR1 10171 Reference 4 rpm per bit 0 to 257 020 2 bytes
Speed rpm
64373 MG1IR1 10172 Reference 0.0625 kW per 0 to 4 2 bytes
Power bit 015.937 5
kW

The parameters that are used in the standard are as follows.

Reference Power – SPN10172

The granularity is 0.0625 kW, with a 16 bit length of the reference power that results in a range from
0 to 4015.9375 kW.

Standard API Definition Page 24 of 53

Reference Current – SPN 10202

The granularity is 0.125 A per bit, with a 16 bit length of the reference power that results in a range
from 0 to 8 031.875 A.

Reference Voltage – SPN 10203

The granularity is 0.125 V per bit, with a 16 bit length of the reference power that results in a range
from 0 to 8 031.875 V.

6.3.5 FCM Actual Current and Voltage

Direction: From FCCU to VCU (in case from external DC/DC to FCCU)

The FCM status informs the application ECU about the actual voltage and current delivery from the
FCM. The values are from the output (HV side) of the DC/DC converter. The values are sent as
percentages of the reference values, which is aligned with how the setpoints are sent from the
application ECU.

If the FCM does not have an integrated DC/DC the value is from the output of the DC/DC converter.

6.3.5.1 Mapping to SAE J1939

The FCM status is sent using the motor/generator inverter status message, PGN 64372. The
transmission interval is 10 ms.
Table 7. Motor/Generator 1 Inverter Status 1

PGN PG label SPN SP label Scaling Range Length

64372 MG1IS1 10173 CRC 1 count per bit
0 to 255 count 1 byte
64372 MG1IS1 10174 Counter 16 states 0 to 15 4 bits
64372 MG1IS1 9061 Torque 0.0625 % per -125 to 12 bits
bit 125.9375 %
64372 MG1IS1 9057 Speed 0.00390625 % -125 to 2 bytes
per bit 125.99609375
%
64372 MG1IS1 10175 Current 0.0625 % per -125 to 12 bits
bit 125.9375 %
64372 MG1IS1 9101 Voltage 0.0625 % per -125 to 12 bits
bit 125.9375 %

The torque and speed status are not used, only the current and voltage parameters.

Current Value – SPN 10175. The actual current output from the high voltage side of the DC/DC
converter, as a percentage of the reference value in SPN 10202.

Voltage Value – SPN 9101. The actual voltage for the high voltage side of the DC/DC converter, as a
percentage of the reference value in SPN 10203.

Standard API Definition Page 25 of 53

6.3.6 Power Limits
Direction: From FCCU to VCU

The maximum and minimum power that can be delivered by the FCM within the next defined period
of time. E.g. in the next one second the FCM can output a certain minimum or maximum power. The
application ECU can use this information to calculate the power available from FCM. The minimum is
the power delivered during FCM idling. A lower power output could cause high stack cell voltage that
may harm the fuel cell stack.

6.3.6.1 Mapping to SAE J1939

The message is implemented using the Motor/Generator 1 Inverter Limits Active Power in J1939, which
provides the maximum and minimum limits for the electrical power. In addition, it contains mechanical
power limits which are not used in the standard.

The transmission interval is 100 ms.

Table 8. Motor/Generator 1 Inverter Limits Active Power {MG1ILAP}.

PGN PG label SPN SP label Scaling Range Length

61826 MG1ILAP 10182 CRC 1 count per 0 to 255 1 byte
bit count
61826 MG1ILAP 10183 Counter 16 states 0 to 15 4 bits
61826 MG1ILAP 10184 Mechanical 0.0625 % per -125 to 12 bits
Power bit 125.9375 %
Maximum
61826 MG1ILAP 10185 Mechanical 0.0625 % per -125 to 12 bits
Power bit 125.9375 %
Minimum
61826 MG1ILAP 10186 Active DC Side 0.0625 % per -125 to 12 bits
Power bit 125.9375 %
Maximum
61826 MG1ILAP 10187 Active DC Side 0.0625 % per -125 to 12 bits
Power bit 125.9375 %
Minimum

The SPNs that are used in the standard are:

Max Power– SPN 10186. The value is the predicted maximum that the FCM will keep the power below.
It is signaled as a percentage of the reference power in SPN 10172.

Min Power– SPN 10867. Minimum value that the FCM can deliver, signaled as a percentage of the
reference power in SPN 10172.

6.3.7 Voltage Limits

Direction: From FCCU to VCU (in case from external DC/DC to FCCU)

The FCM can provide recommended maximum and minimum limits on the operating voltage. These
limits can be used to prevent operating conditions that can damage the battery. The FCM can also
provide the nominal voltage and the nominal power output, which is a fixed value that does not

Standard API Definition Page 26 of 53

depend on state of health. These values shall not change during operation and are therefore only
transmitted when requested by the application ECU.

The voltage value refers to the high voltage side of the DC/DC converter, also in case the DC/DC is
physically external to the FCM.

6.3.7.1 Mapping to SAE J1939

The J1939 parameter group used to implement the message is High Voltage Bus Min and Max Voltage
based on High Voltage Energy Storage System Configuration, PGN 64346. These values are provided as
absolute voltage, current and power. The parameter group is sent on request.
Table 9. High Voltage Bus Min and Max Voltage based on {HVESSCFG}.

PGN PG label SPN SP label Scaling Range Length

64346 HVESSCFG 11132 Nominal Voltage 0.05 V per bit 0 to 3 212.75 2 bytes
V
64346 HVESSCFG 11133 Minimum 0.05 V per bit 0 to 3 212.75 2 bytes
Operating Voltage V
64346 HVESSCFG 11134 Maximum 0.05 V per bit 0 to 3 212.75 2 bytes
Operating Voltage V
64346 HVESSCFG 11135 Minimum State Of 0.001 562 5 % 0 to 100.398 2 bytes
Charge per bit 437 5 %
64346 HVESSCFG 11136 Maximum State 0.001 562 5 % 0 to 100.398 2 bytes
Of Charge per bit 437 5 %
64346 HVESSCFG 11137 Maximum 0.031 25 °C per -273 to 1 2 bytes
Operating bit 734.968 75
Temperature °C
64346 HVESSCFG 11138 Minimum 0.031 25 °C per -273 to 1 2 bytes
Operating bit 734.968 75
Temperature °C
64346 HVESSCFG 11139 Cell Maximum 0.020 44 V per 0 to 5.11 V1 byte
Voltage Limit bit
64346 HVESSCFG 11140 Cell Minimum 0.020 44 V per 0 to 5.11 V 1 byte
Voltage Limit bit
64346 HVESSCFG 15261 Nominal Rated 0.001 kWh per 0 to 3 bytes
Capacity bit 16449.535
kWh

The SPNs that are used in the standard are:

HVESS Nominal Voltage – SPN 11132. The scaling is 0.05 V per bit, with 16 bits that results in a value
range from 0 to 3212.75 V.

HVESS Recommended Minimum Operating Voltage - SPN 11133. The scaling is 0.05 V per bit, with 16
bits that results in a value range from 0 to 3212.75 V.

HVESS Recommended Maximum Operating Voltage - SPN 11134. The scaling is 0.05 V per bit, with 16
bits that results in a value range from 0 to 3212.75 V.

Standard API Definition Page 27 of 53

HVESS Nominal Rated Capacity - SPN 15261. The scaling is 0.001 kWh per bit, with 24 bits that results
in a value range from 0 to 16 449.535 kWh. This value is constant over the lifetime of the FCM and
does not change with state of health.

6.3.8 High Voltage Bus Information

Direction: From VCU to FCCU

This message indicates to the FCM whether the HV bus is available. The system cannot be started if
the HV bus is not available, as the HV bus needs to draw power from the FCM and components
connected to the HV system are not supplied with power, e.g. the coolant pump and compressor. The
status can be one of the following states:

0: Not connected.

1: Connected.

2: Connection in progress.

3: Disconnection in progress.

5: Disconnection is imminent.

14: Error.

6.3.8.1 Mapping to J1939

The message is implemented using the High Voltage Bus Information {HVBI} in J1939. The message is
sent at every second or event-triggered when the status is changed. However, the minimum interval
between transmissions is 100 ms in case of frequent changes of the status.
Table 10. High Voltage Bus Information

PGN PG label SPN SP label Scaling Range Length

64363 HVBI 10298 High Voltage 16 states 0 to 15 4 bits
DC Bus
Availability
64363 HVBI 20802 High Voltage 16 states 0 to 15 4 bits
Bus Driveline
Availability
64363 HVBI 20803 High Voltage 16 states 0 to 15 4 bits
Bus Auxiliaries
Availability
64363 HVBI 20804 High Voltage 16 states 0 to 15 4 bits
Bus ePTO
Availability
64363 HVBI 20805 High Voltage 16 states 0 to 15 4 bits
Bus On-Board
Charger
Availablility
64363 HVBI 20806 High Voltage 16 states 0 to 15 4 bits
Bus Off-Board
Charger
Availablility

Standard API Definition Page 28 of 53

The parameter that shall be used to indicate the connection of the HV DC bus is Driveline Availability
– SPN20820 for HV Connection Status. The values are:

0000b = High voltage DC bus is not connected.

0001b = High voltage DC bus is connected.

0010b = High voltage DC bus connection is in process of being connected.

0011b = High voltage DC bus disconnection is in process. Devices on the bus should take appropriate
action.

0101b = High voltage DC bus disconnect forewarning. Disconnection is imminent.

1110b = Error

1111b = Not Available

The rest of the values are SAE reserved.

6.3.9 FCM Temperature

Direction: From FCCU to VCU

This is an optional message.

This message is used to provide feedback about the FCM temperature for FCMs with multiple sensors.
This message can for example be used to report the temperature of the coolant at the intake and the
outlet. The details of location of the temperature sensors and normal temperature ranges will be
defined by the manufacturer.

6.3.9.1 Mapping to J1939

The FCM temperature message is mapped to the Motor Temperature Status 1 Inverter Status 1 in
J1939. The message transmission interval is one second. Up to four different temperature
measurements can be provided from sensors located at different positions.
Table 11. Motor Temperature Status 1 Inverter Status 1.

PGN PG label SPN SP label Scaling Range Length

64369 MG1IMT 9059 Motor/Generator 1 °C per bit -40 to 210 1 byte
1 Temperature 1 °C
64369 MG1IMT 10220 Motor/Generator 1 °C per bit -40 to 210 1 byte
1 Temperature 2 °C
64369 MG1IMT 10221 Motor/Generator 1 °C per bit -40 to 210 1 byte
1 Temperature 3 °C
64369 MG1IMT 10222 Motor/Generator 1 °C per bit -40 to 210 1 byte
1 Temperature 4 °C

The FCM may use as many of the parameters as needed for the sensor in the FCM.

6.3.10 Air Filter Pressure

Direction: from FCCU to VCU

This is an optional message.

Standard API Definition Page 29 of 53

If the FCM has sensors on the air filter the differential pressure between the sides of the filter can be
an indication of accumulating of particles in the filter and therefore give an indication on when it is
time to replace the filter. It may also be required to fulfil safety requirements in some maritime
applications.

6.3.10.1 Mapping to J1939

The message is mapped to the parameter group Intake/Exhaust Conditions 2, PGN 64976. This PG is
sent every 500 ms.

PGN PG label SPN SP label Scaling Range Length

64976 IC2 2809 Engine Air Filter 0.05 kPa per 0 to 12.5 1 byte
2 Differential bit kPa
Pressure
64976 IC2 2810 Engine Air Filter 0.05 kPa per 0 to 12.5 1 byte
3 Differential bit kPa
Pressure
64976 IC2 2811 Engine Air Filter 0.05 kPa per 0 to 12.5 1 byte
4 Differential bit kPa
Pressure
64976 IC2 3562 Engine Intake 2 kPa per bit 0 to 500 kPa 1 byte
Manifold #2
Pressure
64976 IC2 3563 Engine Intake 2 kPa per bit 0 to 500 kPa 1 byte
Manifold #1
Absolute
Pressure
64976 IC2 4817 Engine Intake 0.1 kPa per bit 0 to 6 425.5 2 bytes
Manifold 1 kPa
Absolute
Pressure (High
Resolution)
64976 IC2 5422 Engine Intake 2 kPa per bit 0 to 500 kPa 1 byte
Manifold 2
Absolute
Pressure

The parameter that is used in the standard is the Air Filter 2 Differential Pressure - SPN 2809.

6.3.11 Fuel Information

Direction: from FCCU to VCU

This is an optional message.

The fuel information is used for the FCM to provide an estimate of the fuel consumption measured in
kg/h. This can be used together with the power output for the application ECU to calculate the
estimated fuel efficiency. The information may also be needed to fulfil the safety requirements in some
maritime applications. There is no requirement specified on the accuracy of the estimate, hence it is
not required to use a flow meter but the FCM can provide an estimate according to its own
implementation.

6.3.11.1 Mapping to J1939

The message is mapped to Fuel Information 3 (Gaseous), PGN 64930. The PG is sent every 500 ms.

Standard API Definition Page 30 of 53

Table 12. Fuel Information 3 (Gaseous).

PGN PG label SPN SP label Scaling Range Length

64930 GFI3 3466 Engine Fuel 0.1 kPa per bit 0 to 6 425.5 2 bytes
Valve 2 Intake kPa
Absolute
Pressure
64930 GFI3 3467 Engine Fuel 0.05 kg/h per 0 to 3 2 bytes
System 2 Gas bit 212.75 kg/h
Mass Flow Rate
64930 GFI3 3468 Engine Fuel 1 1 °C per bit -40 to 210 1 byte
Temperature 2 °C
64930 GFI3 3469 Engine Fuel 0.1 kPa per bit 0 to 6 425.5 2 bytes
Valve 2 Outlet kPa
Absolute
Pressure

The standard includes the gas mass flow rate, SPN 3467, measured in kg/h.

6.3.12 FCM Operating Hours

Direction: From FCCU to VCU

This is an optional message.

The FCM can report the accumulated hours of operation, which can be used in diagnostic and
prognostic functions.

6.3.12.1 Mapping to J1939

The accumulate operating time is implemented using the engine total hours of operation parameter
group in J1939. The parameter group is sent with a 5 second interval.
Table 13. Operating Hours of Fuel Cell Module.

PGN PG label SPN SP label Scaling Range Length

65253 HOURS 247 Engine Total 0.05 h per bit 0 to 210 554 4 bytes
Hours of 060.75 h
Operation
65253 HOURS 249 Engine Total 1 000 r per bit 0 to 4 211 4 bytes
Revolutions 081 215 000
r

Only the hours parameter, SPN 247, is used for the FCM.

The step size is 0.05 h per bit, with a 4 byte data field that results in a range from 0 to 210 554 060.75
hours.

6.3.13 Time and Date

Direction: From VCU to FCCU.

Time and date information is provided from the vehicle to the FCCU to keep the clock synchronized.
The FCCU can use the time and date for time stamping of diagnostic information.

Standard API Definition Page 31 of 53

6.3.13.1 Mapping to J1939
The message is implemented using the Time/Date PG with PGN 65254. The parameter group is sent
by the application ECU only when it is requested by the FCCU.
Table 14. Time/Date parameter group.

PGN PG label SPN SP label Scaling Range Length

65254 TD 959 Seconds 0.25 s per bit 0 to 62.5 s 1 byte
65254 TD 960 Minutes 1 min per bit 0 to 250 min 1 byte
65254 TD 961 Hours 1 h per bit 0 to 250 h 1 byte
65254 TD 963 Month 1 month per 0 to 250 1 byte
bit month
65254 TD 962 Day 0.25 days per 0 to 62.5 1 byte
bit days
65254 TD 964 Year 1 year per bit 1 985 to 2 1 byte
235 year
65254 TD 1601 Local minute 1 min per bit -125 to 125 1 byte
offset min
65254 TD 1602 Local hour offset 1 h per bit -125 to 125 1 byte
h

All the parameters of the PG are used. The time is reported as UTC (Universal Time Coordinate).
However, the parameters local hour offset and local minute offset can be used to report the local
time.

6.3.14 Ambient Conditions

Direction: from VCU to FCCU

This is an optional message.

The ambient temperature can be used to adapt the startup procedure to the ambient temperature,
e.g. freeze start. In addition, the barometric pressure may be used for adapting the operation to the
altitude, e.g. compressor control.

6.3.14.1 Mapping to J1939

The message is mapped to Ambient Conditions, PGN 65269. This parameter group is sent once every
second to the FCCU.

Standard API Definition Page 32 of 53

Table 15. Ambient Conditions parameter group.

PGN PG label SPN SP label Scaling Range Length

65269 AMB 108 Barometric 0.5 kPa 0 to 125 1 byte
Pressure per bit kPa
65269 AMB 170 Cab Interior 0.031 25 -273 to 1 2 bytes
Temperature °C per bit 734.968
75 °C
65269 AMB 171 Ambient Air 0.031 25 -273 to 1 2 bytes
Temperature °C per bit 734.968
75 °C
65269 AMB 172 Engine Intake 1 Air 1 °C per bit -40 to 1 byte
Temperature 210 °C
65269 AMB 79 Road Surface 0.031 25 -273 to 1 2 bytes
Temperature °C per bit 734.968
75 °C

The parameters used in the standard are the Barometric Absolute Pressure, SPN 108, and the
ambient air temperature, SPN 171.

6.3.15 Vehicle Speed

Direction: from VCU to FCCU

This is an optional message.

The vehicle speed can be used as additional information in diagnostics, where different diagnostic
reactions may be performed depending on the speed.

6.3.15.1 Mapping to J1939

The message is implemented using the Tachograph PG, with PGN 65132. This parameter group is
sent every 50 ms.

Standard API Definition Page 33 of 53

Table 16. Tachograph parameter group.

PGN PG label SPN SP label Scaling Range Length

65132 TCO1 1612 Driver 1 working 8 states 0 to 7 3 bits
state
65132 TCO1 1613 Driver 2 working 8 states 0 to 7 3 bits
state
65132 TCO1 1611 Vehicle motion 4 states 0 to 3 2 bits
65132 TCO1 1617 Driver 1 Time 16 states 0 to 15 4 bits
Related States
65132 TCO1 1615 Driver card, 4 states 0 to 3 2 bits
driver 1
65132 TCO1 1614 Vehicle 4 states 0 to 3 2 bits
Overspeed
65132 TCO1 1618 Driver 2 Time 16 states 0 to 15 4 bits
Related States
65132 TCO1 1616 Driver card, 4 states 0 to 3 2 bits
driver 2
65132 TCO1 1622 System event 4 states 0 to 3 2 bits
65132 TCO1 1621 Handling 4 states 0 to 3 2 bits
information
65132 TCO1 1620 Tachograph 4 states 0 to 3 2 bits
performance
65132 TCO1 1619 Direction 4 states 0 to 3 2 bits
indicator
65132 TCO1 1623 Tachograph 0.125 rpm per 0 to 8 2 bytes
output shaft bit 031.875
speed rpm
65132 TCO1 1624 Tachograph 0.003 906 25 0 to 250.996 2 bytes
vehicle speed km/h per bit 093 75 km/h

The parameter that relevant for the StasHH standard are the vehicle speed, SPN 1624.

6.3.16 FCM Gas Leakage

Direction: From FCCU to VCU

This is an optional message.

Detection of hydrogen leakage may be implemented on the FCM, in addition to in the application
system itself. For this reason, a message is defined which can be used by the FCM to notify the
application ECU about a gas leakage. In particular, for applications where it is a safety requirement to
provide an alarm in case of gas leakage this can be used to provide such an alarm. The message has
room for measurement values from multiple sensors which may be placed at different locations.

Standard API Definition Page 34 of 53

6.3.16.1 Mapping to J1939
This message is implemented using the engine gaseous leakage information PG.
Table 17. Engine Gaseous Leakage Information.

PGN PG label SPN SP label Scaling Range Length

64595 EGLI 6834 Gaseous Fuel 0.5 % per bit 0 to 125 % 1 byte
Leakage 1
Concentration
64595 EGLI 6835 Gaseous Fuel 0.5 % per bit 0 to 125 % 1 byte
Leakage 2
Concentration
64595 EGLI 6836 Gaseous Fuel 0.5 % per bit 0 to 125 % 1 byte
Leakage 3
Concentration
64595 EGLI 6837 Gas Leakage 4 kPa per bit 0 to 1 000 1 byte
Detection 1 kPa
Pressure
64595 EGLI 6838 Gas Leakage 4 kPa per bit 0 to 1 000 1 byte
Detection 2 kPa
Pressure
64595 EGLI 6839 Gas Leakage 4 kPa per bit 0 to 1 000 1 byte
Detection 3 kPa
Pressure

The gaseous fuel leakage concentration is relative to the lower explosion limit (LEL). 100% means the
measured value is on the lower explosion limit while 0% means no gaseous fuel is detected at the
measurement point.

The gas leakage detection pressure can the pressure of any mixture of fuel and air, depending on the
failure mode detected.

6.3.17 Alarm Messages

Direction: From FCCU to VCU

The principle used for the alarm messages follows the method used by SAE J1939, i.e. that the active
faults include the severity and an indication of the function or component with the fault. The alarms
are tied to the parameters that are used in the protocol. The exact use of the alarm messages for root
cause analysis etc. is left to the implementation of each FCM.

6.3.17.1 Mapping to J1939

The alarm messages are implemented using the parameter group Active Diagnostic Trouble Codes in
J1939. This is known as Diagnostic Message 1, which indicates the active fault messages at any time.

Standard API Definition Page 35 of 53

Table 18. Diagnostic message 1.

PGN PG label SPN SP label

65226 DM1 987 Protect Lamp
65226 DM1 624 Amber Warning Lamp
65226 DM1 623 Red Stop Lamp
65226 DM1 1213 Malfunction Indicator Lamp
65226 DM1 3041 Flash Protect Lamp
65226 DM1 3040 Flash Amber Warning Lamp (AWL)
65226 DM1 3039 Flash Red Stop Lamp (RSL)
65226 DM1 3038 Flash Malfunction Indicator Lamp
65226 DM1 1214 Suspect Parameter Number
65226 DM1 1215 Failure Mode Identifier
65226 DM1 1216 Occurrence Count
65226 DM1 1706 SPN Conversion Method

Details of the use of specific combinations of SPNs, FMIs and lamps are defined by the manufacturers
and OEMs. However, some guidelines are described here.

6.3.17.1.1 Lamp SPNs

For the lamp status SPNs (987, 624 and 623) the values are:

00b = lamp off

01b = lamp on

The malfunction indicator lamp (SPN 1213) should not be used, because it has to do with the legal
requirements on exhaust emissions. Fuel cells are not part of these legislation.

For warnings that do not require the vehicle to stop immediately, the amber warning lamp (SPN 624)
should be used. This can be used when the FCM need to stop but the rest of the system (e.g. vehicle)
can continue to operate with another power source.

The protect Lamp (SPN 987) can be used for problems of the fuel cell not related to the electronic part.

The red stop lamp (SPN 623) shall only be used for severe conditions that requires the system (e.g. the
vehicle) to stop.

6.3.17.1.2 Suspect Parameter Number

The use of the SPNs in the DM1 is mainly left to the FCM manufacturer because of the need to handle
the internal layout and technologies. However, the following guidelines are recommended:

1 If a problem can be reported with a standard SPN in a certain Parameter Group (PGN 0 –
PGN 65279), that SPN need to be used first
2 If a problem can be reported with a standard SPN that is not linked to a certain Parameter
Group, that SPN need to be used.
3 If a problem will be reported with a FMI = 14, then the range 611 – 615 need to be used.
These SPNs are system diagnostic codes defined by the manufacturer and used for failures
that cannot be tied to a specific component.

Standard API Definition Page 36 of 53

 4 If a problem cannot be reported with the first 3 rules, then the proprietary range need to
be used. The SPNs that are reserved for proprietary diagnostics are 516096 to 524287, i.d.
a range of 8192 SPNs.

6.3.17.1.3 Fault Mode Indicator

The fault mode indicators that can be used in SPN 1215 are as listed in Table 19. For more information
refer to the annex of J1939/73.
Table 19. Fault mode indicators.

FMI Description
0 High – most severe (3)
1 Low – most severe (3)
2 Erratic, Intermittent, or Incorrect
3 Voltage Above Normal
4 Voltage Below Normal
5 Current Below Normal
6 Current Above Normal
7 Not Responding Properly
8 Abnormal Frequency, Pulse Width, or Period
9 Abnormal Update Rate
10 Abnormal Rate of Change
11 Other Failure Mode
12 Failure
13 Out of Calibration
14 Special Instruction
15 High – least severe (1)
16 High – moderate severity (2)
17 Low – least severe (1)
18 Low – moderate severity (2)
19 Data Error
20 Data Drifted High
21 Data Drifted Low
22-30 Reserved
31 Condition exists

6.4 J1939 Signals Summary

The signals that have been defined for the protocol from J1939 are listed in Table 20 and Table 21. For
most of the parameter groups the data length has been specified to 8 bytes, even if not all the bits are
used in this standard. In addition, there will be 64 header bits as well as bit stuffing added to maintain
synchronization, in a worst case scenario the overhead is around 90 bits. Parameter groups that have
more than 8 bytes will be sent as multipacket messages using the J1939 transport protocol. The DM1
will be sent each second in case there is at least one active trouble code, and the length depends on
the number of active trouble codes. The HVBI may also be sent more often than every second in case
of changes in the HV bus availability. The total data rate for one FCM is below 50 kb/s, hence it is
possible to have multiple FCMs sharing the same CAN bus.

Standard API Definition Page 37 of 53

Table 20. J1939 signals and data rate calculation, FCCU Tx messages.

PG interval (ms) overhead (bit) size (bit) bitrate (kb/s)

DM1 1000 90 64 0.154
EGLI 500 90 64 0.308
GFI3 500 90 64 0.308
HOURS 0 90 64 0
IC2 500 90 64 0.308
MG1ILAP 100 90 64 1.54
MG1IMF1 100 90 64 1.54
MG1IMT 1000 90 64 0.154
MG1IR1 1000 90 64 0.154
MG1IR2 1000 90 64 0.154
MG1IS1 10 90 64 15.4
RQST_FCCU 0 90 24 0

Total 20.02

Table 21. J1939 signals and data rate calculation, FCCU Rx messages.

PG interval (ms) overhead (bit) size (bit) bitrate (kb/s)

AMB 1000 90 64 0.154
HVBI 100 90 64 1.54
HVESS1C1 20 90 64 7.7
HVESS1CFG 0 90 160 0
MG1IC 10 90 64 15.4
RQST_VCU 0 90 24 0
TCO1 50 90 64 3.08
TD 0 90 64 0
TPCM_VCU 0 90 112 0
TPDT_VCU 0 90 64 0

Total 27.841
6.5 Power-up Sequence
When powering up the whole vehicle (truck, train, ship,…), the main controller (VCU) should be aware
of the amount and status of the connected FCMs. The VCU will, once supplied with power, start
sending its CAN messages.

The standard support triggering of the wake-up procedure of the FCCU by different sources. Either the
VCU and FCCU share the same LV supply, so the power on and wake up will be performed
simultaneously. The next option would be the hardwired wake-up signal input to the FCCU. If the wake-
up signal is inactive the FCCU may listening on CAN for a wake-up signal.

Standard API Definition Page 38 of 53

Then, the connected FCCUs will perform a wake-up procedure and, after an initialization phase, start
their communication. Once FCCU feedback is processed by the VCU, further power up actions can be
triggered if required.

The timeline of this procedure is shown in Figure 6. Startup procedure.Figure 6.

The green blocks are indicating signals sent by the main ECU, here called VCU.

The blue blocks are indicating signals sent by the FCCU.

The example values are shown in the orange blocks.

The content in the bright blue blocks are explaining actions or actual states referred to the values.

The procedure is focusing on the main communication, so some signals defined in this document are
not considered.

After switching on the LV power, the VCU and FCCU are started. The VCU is waking up the FCCU by
LV enable, CAN trigger or a hardwired wakeup signal.
Once powered, the FCCU sends it initial state (0). The VCU sends a standby request (2) to prepare the
FCM for power delivery.
When the FCCU is in standby, the VCU requests to start in DC current control mode (10), which will
be followed by the FCCU.

Standard API Definition Page 39 of 53

 Figure 6. Startup procedure.

Standard API Definition Page 40 of 53

6.6 Power and State Procedure
In this section an example of the control of the FCMs is provided for illustration of the protocol
operation. First, the VCU sends a FCCU state request to start up the FCM.
The FCCU will respond with the actual and predicted electrical conditions. Moreover, the maximum
and minimum values as reference for the set point are sent to VCU. Based on this feedback and the
selected set point unit (by the state request) the VCU will provide a set point for the FCCU.

In the Figure 7 the communication procedure for the power request is shown.

This example continues the previous power up sequence. The electrical values shown in the diagram
for indicating the procedure are in dependency of the FCM setup, efficiency, SOH and operating
condition.

The FCM is started (10) and the VCU state request is still in the current control mode. It is operating at
minimum power (5kW), and providing its respective electrical outputs (10A, 500V). Within the next
short period of time the power can be immediately increased to 10kW, but not further decreased (as
actual operation is at minimum power to avoid OCV). Also the maximum electrical boundaries are sent
to the VCU (500A, 600V, 100kW).

In the next step the VCU is requesting a current setpoint (20%) as of the reference current (500A) from
the FCCU.

Now the FCCU increase its power output and feedbacks the actual current (100A).

Standard API Definition Page 41 of 53

 Figure 7. Power and state management.

Standard API Definition Page 42 of 53

6.7 Control of External DC/DC
There are FCM variants possible, where the FC DC/DC converter is not part of the FCM. This
architecture, shown in the Figure 7, has the advantage that it can be integrated easier into existing or
different variations of high voltage architecture concepts than integrated DC/DC converters.

Figure 8. External DC/DC converter.

The interface standardization covers also this variant, so the proposed approach can be reused. The
condition is that the external DC/DC converter is supporting the protocol.

In the Figure 9 the diagram from the previous chapter got extended by the external DC/DC
communication.
The signals to and from the external DC/DC have the same PG and SPN, but have different source and
destination addresses. This makes it possible to share the same communication bus following the
J1939 approach.

In the example the FCCU is operating at 25% of maximum current as per DC/DC feedback. Once the
VCU requests 90%, the FCCU is calculating the absolute current setpoint and forward it to the DC/DC
(450A).

Standard API Definition Page 43 of 53

 Figure 9. Protocol with external DC/DC converter.

Standard API Definition Page 44 of 53

The DC/DC converter requires additional control signals, which are not shown in the chart. There is
usually also a state request signal, which indicates the converter to start, stop, precharge, discharge or
to perform further operations.

Standard API Definition Page 45 of 53

7 Physical Connectors
The physical connector needs to fulfil the requirement of having enough pins to transfer all the
electrical signals that are needed. In addition, it needs to be adapted to the working environments of
the different application systems.

The following pins are included in the connector:

1. CAN ground
2. CAN high
3. CAN low
4. OPTIONAL shield
5. Wakeup signal
6. Emergency stop

The following optional pins are also specified:

7. OPTIONAL HVIL in
8. OPTIONAL HVIL out
9. OPTIONAL 24V
10. OPTIONAL ground for LV power
11. OPTIONAL CAN high for DC/DC or secondary FCM
12. OPTIONAL CAN low for DC/DC or secondary FCM
13. OPTIONAL CAN high manufacturer specific diagnostic bus
14. OPTIONAL CAN low manufacturer specific diagnostic bus

In addition, it is considered beneficial to include a few additional pins in the connector for future use,
and for deployments where additional

15. Not specified

16. Not specified
17. Not specified
18. Not specified

The proposed pinout can be found in Figure 10.

Figure 10 Pinout

Since it is difficult to find a suitable connector that fulfils the requirements and is available from
multiple sources there is no specific connector required by the standard. The proposal is to use a
connector with at least the mandatory pins. A recommendation is to use an 18 pin connector to have
the possibility to include additional functions if needed.

The main requirement that has been identified is to have an ingress protection level of IP54. However,
additional requirements may be coming from different application areas or OEMs. For ships an

Standard API Definition Page 46 of 53

important requirement is that the cables do not loosen due to vibrations. Therefore, a common
solution is to use terminator blocks instead of connectors.

In case the same cable is used for LV power supply, the cable cross-section and current ratings have to
be considered. The requirements may differ between different applications due to different cable
lengths and regulations for different industries.

For the purpose of testing the FCMs within the StasHH project an example connector is used. This is a
heavy duty sealed connector from TE connectivity, with number 1-1564526-1, an 18 pin connector
with classification IP67 for ingress protection.

Figure 11. Example of a compliant connector that is used for the test rigs.

Note that the connector is only specified to handle up to 20 Ampere current, and the power supply
through the supply voltage is therefore only intended for the FCCU.

For the connection between primary and secondary FCMs, or between FCM and external DC/DC, the
pins for the secondary CAN bus on the same connector is used.

Standard API Definition Page 47 of 53

8 Implementation over Ethernet
The protocol is intended to be possible to implement also over other types of networks than CAN. In
particular, Ethernet is of interest due to its wide adoption and high performance. Implementation
directly over Ethernet without IP is not considered, since there is no dedicated Ethertype that can be
used to identify the protocol. The Ethertype is encoded in the Ethernet frame header to indicate which
protocol is used in the payload of the Ethernet frame, and there is no such code that indicates SAE
J1939. Instead, implementation should be over IP and a transport protocol, either TCP or UDP. TCP has
the advantage of including mechanisms for reliability, especially CRC, acknowledgement and
retransmission. The drawback is the higher complexity to maintain connections between the ECUs.
UDP has the advantage of lower complexity and support for multicast transmission but lack reliability
functions.

The encoding of the messages defined in Section 6.3 can be done with each parameter separately or
as complete parameter groups. Sending the complete parameter group can be beneficial to keep the
implementation as close as possible to the CAN protocol, with straightforward interoperability.
Separate parameters provide a simpler handling of parameters in software. In terms of efficiency,
sending the full parameter group includes extra bits for parameters that are not used, while it is a more
efficient encoding of parameters with less than one byte.

As a guideline, a simple implementation with the complete parameter groups sent over UDP, with the
J1939 CRC implemented can be used for implementations where code reuse and integration with CAN
bus implementation is needed. An implementation over TCP with separate parameters can be used
where it is not expected to interwork with CAN bus implementations.

Standard API Definition Page 48 of 53

9 Conclusion
This document specifies the first release of the StasHH digital interface standard for FCMs. Feedback
on the proposed standard is welcome and it is anticipated that updates can be made to the standard
to have a new release by the end of the StasHH project, and possibly intermediary releases if needed.

It has been a goal to cover the requirements from different application areas, to make the standard
applicable for a wide range of markets. For the physical connector only the basic requirements have
been included in the standard. The specific connector is left open to avoid lock-in to a single supplier
and to allow for flexibility for different applications that may add new requirements.

The messages have been defined with mappings to J1939 in order to reuse established standards as
much as possible. This is convenient in particular for the trucks, buses and other vehicles that already
use J1939. Following the guidelines from SAE existing messages have been reused as much as possible.
The standard has primarily used the motor/generator parameter groups in the modelling of the fuel
cell module, but some additional parameter groups have been added to cover information that may
be needed. Since the design of the FCMs and systems is likely to have a significant variation several
parameter groups have been made optional.

The standard is also intended to be useful over other networks than CAN, in particular Ethernet. This
will be implemented over IP and TCP or UDP. The details of such implementation is left as future work.

Standard API Definition Page 49 of 53

10 Appendix: Related Standards
In this appendix the most relevant standards are briefly reviewed to provide a background for the
decisions about the standard. The chapter is divided into sections on the lower layers and higher layers,
and a conclusion on the best options.

10.1 Lower Layers

10.1.1 CAN
CAN bus is widely deployed in the automotive sector to connect different ECUs within a vehicle. The
first version dates back to the 1980's, with improved versions developed over time. The physical layer
supports a bus topology over two wires that operate with a high and low voltage respectively. The
medium access control is designed with dominating and recessive bits in the beginning of the source
address, which allows prioritization of different ECUs to be implemented based on the respective
addresses.

Two different frame formats can be configured in a CAN network, with 11 bit or 29 bit identifiers. The
29 bit identifier format is used for J1939, and in this standard. The frame format of CAN can be seen in
Figure 12. SOF and EOF are the start of frame and end of frame markers. The ACK field is used to
acknowledge the reception of a frame. A positive acknowledgement is sent with a dominant level such
that the sender will get an acknowledge that the frame was received by at least one receiver.

SOF Identifier Control Data CRC ACK EOF

Figure 12. CAN frame format.

There are a number of different parameters in the implementation that can be selected for different
applications. For example, the baud rate, the byte order and the length of the identifiers can be
changed. Therefore, different profiles have been developed, and there is need to agree on the
parameters to use for a common standard.

There is no single standard connector defined for CAN bus, but a 9-pin D-Sub with CAN-low, CAN-high,
ground and power is a commonly used connector. However, for implementation in a vehicle a more
rugged connector is preferred. The only strictly required lines in the cable are the high and low signals,
while CAN ground is beneficial but not strictly necessary.

10.1.1.1 CAN FD
CAN-FD was introduced in 2012 as a backward compatible protocol that can address bottlenecks in
CAN bus through increased data transmission rate. The higher bit rates allow more devices to connect
to the same bus without splitting with gateways.

The CAN-FD header has three new bits in the control field:

Extended Data Length (EDL)

Bit Rate Switch (BRS)

Error State Indicator (ESI).

The EDL and BRS fields are designed for compatibility with original CAN when needed, by using
recessive bits for switching to the CAN FD frames.

Standard API Definition Page 50 of 53

For arbitration the common bit rate is used in the initial bits of a frame. For a large number of bits in
the frame CAN-FD is more efficient since the data frame bits are sent with higher rate. However, there
is some additional overhead, which makes it less efficient for the same bit rate. It will be useful to
reduce the load on the CAN bus, while it is compatible with long cables, e.g. in trains and ships.

10.1.2 Ethernet
Ethernet is the most relevant alternative to CAN bus. Due to its very wide use in both industrial and
office settings there is widely available SW and HW support, and high performance is available for a
relatively modest cost. Ethernet is standardized by IEEE as a set of complementing specifications that
are evolving to cover different applications and new requirements.

10.1.2.1 Automotive Ethernet

Automotive Ethernet has developed from standard Ethernet to cover requirements of the automotive
sector. A major differentiator is the use of 10Base-T1S which specifies Physical Layer Collision
Avoidance (PLCA) for a bus topology. Traditionally Ethernet has used Carrier Sense Multiple Access
with Collision Detection (CSMA/CD) when it is deployed over bus topologies, which result in random
delays and performance that deteriorates at high load. With PLCA the performance is more
deterministic and the bus can be highly loaded without the throughput collapsing. In PLCA there is one
coordinator node on the bus which sends a beacon which starts a beacon interval, and each node on
the bus has a transmission opportunity during the beacon interval. This results in a fair distribution of
resources and a deterministic upper bound on the delay. It is possible to detect when one of the nodes
are not using its transmission opportunity, and it is also possible to configure such that different nodes
can transmit different number of frames. Hence, the efficiency can be kept high, and the delay is not
entirely deterministic since the beacon interval can depend on how much the nodes have to transmit.

There is also an ongoing effort in IEEE to develop a profile of Time Sensitive Network (TSN) for
automotive applications, under the label 802.1DG. In TSN the nodes on a network are synchronized to
a common clock, and the scheduling at each of the nodes can therefore be synchronized. The delay
can then be deterministic with very low variation.

The Ethernet standards also include security at the link layer, which can be used in automotive
Ethernet. In particular 802.1AE for point-to-point security is considered suitable. It adds security tags
and integrity check values to the Ethernet frames, such that secure channels can be used between
pairs of nodes.

The most common Ethernet physical connector is RJ45. However, for automotive applications there is
a long range of alternative connectors that are better adapted to the requirements of automotive
applications.

10.2 Higher Layers

10.2.1 SAE J1939
SAE J1939 is a standard that is widely adopted for heavy duty vehicles that defines a protocol for
communication over CAN bus. It also serves as basis for standards for maritime and agricultural vehicle
communication standards. J1939 defines Parameter Group Numbers (PGN), i.e. messages, and Suspect
Parameter Numbers (SPN) which are the signals in the messages. It is a large standard that includes
over 1060 PGNs, and over 6400 SPNs.

Standard API Definition Page 51 of 53

The data link layer uses 29 bit identifiers in Protocol Data Units (PDU) which consists of an identifier
and data. J1939 document also describes 5 types of message types: Commands, Requests,
Broadcasts/Responses, Acknowledgment, and Group Functions. Connection Management (CM)
messages for handling the communication of segmented messages: Request to Send (RTS), Clear to
Send (CTS) and Broadcast Announce Message (BAM).

The Network Layer specification describes the services and functions needed for intercommunication
between different segments of a J1939 network. It defines four ECU types that provide functions for
network interconnection between segments: Repeater (forwarding), Bridge (forwarding and filtering),
Router (forward, filter, and address translation), and Gateway (forward, filter, address translation, and
message repackaging).

The Vehicle Application Layer defines “standard” parameters which are grouped together in a message
frame and given a PGN. There are different lengths of parameters defined in the standard 1, 2, 4 bytes.
For the StasHH standard the definition of the vehicle application layer is the most important aspect.

In addition, there is an application layer for diagnostics defined, which includes several types of
diagnostics messages, i.e. parameter groups, that can be used to implement complex and powerful
diagnostic functionality.

10.3 Diagnostics
10.3.1 Unified Diagnostic Services
UDS is a standard for diagnostics that has is specified in ISO 14229-1. It specifies the application and
session layers of the OSI stack for communication between a diagnostic testing instrument, e.g. in a
workshop, and the ECUs in the vehicle. The standard originates from the car industry but has an
increasing popularity for heavy vehicles.

UDS defines a client-server protocol for diagnostics where the ECU acts as server and the tester as the
client. The protocol is designed to work on different types of lower layers, for example CAN bus.

When used on CAN, the protocol uses the CAN IP for routing between the tester and the ECUs. There
are a number of different services defined that can be requested by the client for:

• Diagnostics and communications management, including session control and security

functions
• Data Transmission, for reading and writing data specified by identifiers or memory addresses
• Stored data transmission, for reading or deleting stored DTCs.
• Input/Output control, to allow external systems to intervene with signals, for example to reset
signals to default values or freeze the signal value.
• Remote activation of routine, to start and stop different service routines, and to request the
results.
• Upload/download, for uploading and downloading software to an ECU.

The client may also return a negative response if a service request cannot be performed.

10.3.2 Diagnostics over IP

DoIP has an application layer which is similar to UDS, but with transport over Ethernet and TCP/IP
instead of CAN bus. A practical deployment approach is to have a gateway in the vehicle that connects

Standard API Definition Page 52 of 53

the internal UDS over CAN to an external IP network. An alternative to this is to have a telematics unit
in the vehicle that acts as a tester for UDS services over CAN in the vehicle.

Standard API Definition Page 53 of 53