ARINC Basic Guide

this basic guide is intended for users that are unfamiliar with the arinc 825 specification and wish to implement the hargrave arinc 825 message set in a can 2 0b system this basic guide will cover the basic can id structure of messages and provide details on how to control, configure and read telemetry from a device can arbitration id unless stated otherwise, the correct can id for a message can be generated by left bit shifting the sid and bitwise or ing that with the base can id 0xxxxxxxxx | (sid << 2) for a message with a base can id of 0x12345600, the can id for sid 1 would be 0x12345604 basic arinc id structure can bus activation the arinc 825 sub system on the device will only begin operating once traffic is detected on the can bus the first message a device receives after powering on will not be processed, therefore it will not be responded to it is recommended for the system to send a periodic health status message (phsm) at 1hz, documentation for the phsm can be found below for bus activation purposes this message can simply be the following can packet the basic bus activation message can id 0x1bed15f4 payload bytes datatype content 0 7 0x0 payload can be all 0 control and telemetry details about the control and telemetry message set can be found at the below link periodic health status message (phsm) the device will broadcast a periodic health status message (phsm) at a default rate of 1hz, this rate is configurable the phsm acts as a sign of life from a node on the bus as well as informing the bus of can errors can id the phsm message can id is 0x1bed1600 | (sid << 2) where sid is the sid of the device sending the message for sid 1 the can id is 0x1bed1604 payload bytes datatype content 0 1 uint16 err rx total detected receive errors since boot resets to 0 upon counter overflow 2 3 uint16 err tx total detected transmit errors since boot resets to 0 upon counter overflow 4 5 uint16 err ack total detected acknowledgement errors since boot resets to 0 upon counter overflow 6 uint8 total detected bus off errors since boot resets to 0 upon counter overflow 7 4 bit bit field + 4 bit bit field r/t receive/transmit error states as defined in the arinc specification hargrave protocol tunnel a series of messages have been implemented to allow communication with the hargrave configurator, this allows for a more convenient and more reliable configuration and firmware updating experience these messages have the following can ids request 0x1bfd1600 | (sid << 2) response 0x1bf91600 | (sid << 2) node services the below functionality can be performed over arinc using the hargrave configurator via slcan or mavlink a variety of ‘node services’ have been implemented to perform configuration and non control operations the can id does not change between the different node services, however the request and response can ids are different node services are distinguished by a service function code (sfc) in the can payload as shown below requests are sent by the system and the device will send back a response image png request can id 0x13fc1600 | (sid << 2) the request can id is 0x13fc1600 | (sid << 2) where sid is the target device sid for sid 1 the can id is 0x13fc1604 response can id 0x13f81600 | (sid << 2) the response can id is 0x13f81600 | (sid << 2) where sid is the request target device sid for sid 1 the can id is 0x13f81604 verifying device hardware the line replaceable unit (lru) code can be requested from a node alongside other identifying information this request can be used to verify the hardware of the device as the lru code is the pcba of the device truncated to 16 bits request 0x13fc1600 | (sid << 2) the request payload is structured as follows bytes datatype content 0 1 uint16 sfc 0x0 image png response 0x13f81600 | (sid << 2) the response payload is structured as follows bytes datatype content 0 1 uint16 sfc 0x0 2 3 uint16 profile id 4 5 uint16 profile sub id 6 7 uint16 lru code image png profile id a statically defined value intended to indicate the communication profile of the device, such as what messages it supports configurable via a device setting profile sub id the value to the right of the decimal place of the profile id configurable via a device setting lru code the line replaceable unit code of the device derived from the device pcba verifying device firmware a request can be sent do a device to retrieve a 32 bit firmware build hash that can be used to verify which build of firmware is running on the device the firmware build hashes can be found in the product documentation request 0x13fc1600 | (sid << 2) the request payload is structured as follows bytes datatype content 0 1 uint16 sfc 0xc000 image png response 0x13f81600 | (sid << 2) the response payload is structured as follows bytes datatype content 0 1 uint16 sfc 0xc000 2 5 uint32 32 bit firmware build hash image png verifying device configuration the device configuration can be verified by requesting a computed hash of the values of a given subset of settings the following hash types are supported hash type settings subset 0x00 all settings 0x01 group settings settings that are typically kept the same between lrus on a vehicle 0x02 protected settings settings that are not individually configurable if configured incorrectly, these settings could cause damage to your device the process for verifying device configuration with settings hash values is as follows arinc diagrams settings hash drawio png configuring device settings the hargrave configurator supports connecting to a device over arinc 825 for device configuration device settings can be changed and then saved to the device using arinc node service messages setting ids can be located in the product documentation setting types and values the following types are supported over node services code type 0x01 bool 0x02 uint8 0x03 uint16 0x04 uint32 0x09 float32 setting values in parameter handling node services are a maximum of 4 bytes and have the following memory representation for the above types image png this type will be indicated with the term setting value configuration procedure the hargrave arinc 825 message set includes a series of messages for changing device settings these configuration services must be unlocked before they can be used, all configuration services are unlocked together, the command to commit changed settings to device storage must be unlocked separately multiple settings can be changed before the settings are saved to the device it is not mandatory to retrieve the setting type and bounds before changing the setting, the device will ensure that the value in a settings set request is valid settings changes will not take effect until after the settings save command is sent and the device restarts if a command with an invalid setting id is sent, the response payload will contain 0’s for setting id and setting value field if an invalid setting value is sent in a settings set request then the device will respond with the original unchanged setting value below is an overview of the procedure to configure settings arinc diagrams configuration drawio(2) png resetting device settings follow the below process to reset the device configuration arinc diagrams reset config drawio png restarting a device the restart service is used to request a device to reboot depending on the state the device is in (e g motor drive) it may reject a restart request request 0x13fc1600 the request payload is structured as follows bytes datatype content 0 1 uint16 sfc 0xc001 image png response 0x13f81600 the response payload is structured as follows bytes datatype content 0 1 uint16 sfc 0xc001 2 int8 ack 0 nack 1 image png firmware updating firmware updates can be performed over arinc using the hargrave configurator via slcan or mavlink the firmware update process begins with enabling the firmware updating service, then a handshake to agree on the parameters for the transfer, the data messages, and then a final acknowledgement on if the transfer was successful data messages have a different id to regular node service messages request id 0x13fd1600 | (sid << 2) the total data payload to be sent will be the entire firmware payload + a 4 byte crc32 the ieee 802 3 ethernet crc32 is used, also known as the iso hdlc crc a test input of the character string ‘123456789’ should result in the output 0xcbf43926 step 1 initiate the firmware update in step 3, the system sends a request which specifies the timing between each individual data message this value should be adjusted based on system bandwidth and can bus integrity the firmware update process will timeout after 50 times the the maximum of inter message and inter block spacing duration arinc diagrams firmware update 2 export drawio(1) png step 2 send data payload data messages use a different can id to the normal request messages data messages use the can id of 0x13fd1600 | (sid << 2) the payload (firmware file + 4 byte crc32) must be sent as follows, immediately after the initialization sequence image png each data message will be 8 bytes of the data payload the final data messsage of the final data block may not be the full 8 byte length, and the final data block may not be the full 256 messages each data message is structured as follows image png if an error occurs during the update process the device will respond with the following message, if this message is received the firmware update should be aborted and the device should be restarted image png the crc should be sent immediately after the firmware data as follows image png step 3 receive update result status once all data messages have been received the device will respond with the following message if the ‘transfer success’ response is received the device should be restarted to update the firmware final response message