Skip to content

Commit 3a71cfe

Browse files
mheimhei
authored
Merge pull request #49 from stefannagelchargebyte/everest/charge_som
Added the protocol
2 parents 42175c0 + c6c8ddb commit 3a71cfe

7 files changed

Lines changed: 1215 additions & 1 deletion

File tree

‎docs/source/_static/images/safety_controller_states.svg‎

Lines changed: 1 addition & 0 deletions
Loading

‎docs/source/_static/images/system_architecture.svg‎

Lines changed: 1 addition & 0 deletions
Loading

‎docs/source/hardware.rst‎

Lines changed: 104 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -99,11 +99,114 @@ in the following table.
9999
| Stopbits | 1 |
100100
+-----------------+-------------+
101101

102+
System Architecture
103+
===================
104+
.. figure:: _static/images/system_architecture.svg
105+
:width: 1000pt
106+
107+
Figure: Simplified system architecture for the safety controller on the chargeSOM
108+
109+
The safety controller manages the Control Pilot (CP) line, acting as a critical interface for monitoring and controlling the high-voltage (HV) system in accordance with EV safety standards. Its core function is to **enforce safe operating states** based on system diagnostics and environmental conditions.
110+
111+
Fault Detection & Safety Response
112+
---------------------------------
113+
114+
When an error is detected—such as a fault in the system, a triggered emergency input, or a thermal violation—the controller transitions to **State F**, a fail-safe state that prevents further system operation to protect both the hardware and the user.
115+
116+
HV Ready Enablement
117+
-------------------
118+
119+
The controller verifies that **no system errors are present** and that the CP line is in **State C**. Only under these safe conditions does it enable the HV Ready signal, which may be used to energize the HV interlock or permit charging/operation.
120+
121+
Emergency Inputs
122+
----------------------------------
123+
124+
The simplified system architecture shows only one emergency input. In the real system, there are 3 independent emergency input signals available: SAFETY_ESTOP1, SAFETY_ESTOP2 and SAFETY_ESTOP3. The inputs are active low. This means an emergency stop needs to pull the input to Gnd. The emergency inputs can be parameterized out.
125+
126+
127+
Temperature Monitoring
128+
----------------------------------
129+
130+
The simplified system architecture shows only one temperature input. In the real system, there are 4 independent temperature measurement circuits for PT1000 sensors. The safety software monitors the temperature circuit for hardware errors and for overtemperaure. The temperature threshold can be parameterized.
131+
132+
HV Connector Control
133+
--------------------
134+
135+
If State C is confirmed and all safety criteria are met, the controller is also capable of closing HV connectors to complete the high-voltage path. Therefore it enables the 2 connectors SAFETY_HVSW1_HS and SAFETY_HVSW2_HS under the condition that State C is detected, the system is HV-ready and the host processor commands to close the contactors.
136+
137+
138+
Reset Behaviour and Controller states
139+
=====================================
140+
The safety controller starts in an initialization state, to give the peripherals time to reach an defined state. It leaves the initialization state to a running state, after the reception of the first UART message from the host. Only periodic messages leaves the init state. With the reception of inquiriy messages, the safety controller stays in initialization. This gives the option to fetch version information in an init state. In running state, it monitors the peripherals and sends out UART messages. If any error occurs, the system goes into safe state. This state can only be left by a reset.
141+
142+
.. figure:: _static/images/safety_controller_states.svg
143+
:width: 1000pt
144+
145+
102146

103147
Safety Controller Communication Protocol
104148
========================================
105149

106-
TBD
150+
Packet format descriptions
151+
--------------------------
152+
153+
Data packet format
154+
155+
Data packets contain payload and can be sent out from host to safety controller or vice versa. Data packets from safety controller to host can be transmitted periodically or by request via an inquiry packet. Only one inquiry packet can be requested before requesting the next one.
156+
157+
+--------+--------+--------+-------------------+
158+
| Symbol | Size | Code | Description |
159+
+========+========+========+===================+
160+
| SOF | 1 byte | 0xA5 | Start of frame |
161+
+--------+--------+--------+-------------------+
162+
| ID | 1 byte | | Packet Identifier |
163+
+--------+--------+--------+-------------------+
164+
| Data | 8 byte | | Payload |
165+
+--------+--------+--------+-------------------+
166+
| CRC | 1 byte | | CRC checksum |
167+
+--------+--------+--------+-------------------+
168+
| EOF | 1 byte | 0x03 | End of frame |
169+
+--------+--------+--------+-------------------+
170+
171+
172+
Packet Identifier (ID)
173+
----------------------
174+
175+
The values of the packet identifier (PacketId) are mapped to the messages as summarized below.
176+
177+
+----------+---------------------------+---------------------+-------------------------------------------------------------+----------------------+
178+
| PacketId | Description | Communication Dir. | Periodicity | Triggered by Inquiry |
179+
+==========+===========================+=====================+=============================================================+======================+
180+
| 0x06 | Charge Control | Host → Safety | periodically, every 100ms OR immediately if changes occur | No |
181+
+----------+---------------------------+---------------------+-------------------------------------------------------------+----------------------+
182+
| 0x07 | Charge State | Safety → Host | periodically, every 100ms | No |
183+
+----------+---------------------------+---------------------+-------------------------------------------------------------+----------------------+
184+
| 0x08 | PT1000 State | Safety → Host | periodically, every 100ms | No |
185+
+----------+---------------------------+---------------------+-------------------------------------------------------------+----------------------+
186+
| 0x0A | Firmware Version | Safety → Host | no, only upon request via inquiry packet | Yes |
187+
+----------+---------------------------+---------------------+-------------------------------------------------------------+----------------------+
188+
| 0x0B | GIT Hash | Safety → Host | no, only upon request via inquiry packet | Yes |
189+
+----------+---------------------------+---------------------+-------------------------------------------------------------+----------------------+
190+
| 0xFF | Inquiry packet | Host → Safety | no, only to trigger inquiries | No |
191+
+----------+---------------------------+---------------------+-------------------------------------------------------------+----------------------+
192+
193+
CRC checksum field
194+
------------------
195+
196+
The checksum is defined over:
197+
198+
::
199+
200+
Width = 8
201+
Poly = 0x1d
202+
XorIn = 0xff
203+
ReflectIn = False
204+
XorOut = 0xff
205+
ReflectOut = False
206+
Algorithm = table-driven
207+
Name = CRC8 SAE J1850
208+
209+
.. include:: safety_protocol.rst
107210

108211

109212
EVerest Board Support Package Module

0 commit comments

Comments
 (0)