Communication stack
Supported communication interfaces
Each YOS device supports multiple communication interfaces, allowing to connect various peripherals, such as display, sensors, BMS or another controller. All of these interfaces can be also used for controller setting, state monitoring and firmware update over internet. Communication was designed specifically for hard real-time system needs, with minimal latency and perfect synchronization of multiple controllers in one system. Another focus is the pursuit of abstraction from the used physical layer. Commonly, we support these communication interfaces:
- SWD
- USB
- Bluetooth
- UDP/IP
- UART (up to 4x)
- CAN Bus (up to 2x)
- LIN Bus (up to 2x)
siliXcon network topology
The YOS communication stack is organized into a layered architecture designed to fully abstract the application from the underlying physical interface. Regardless of whether the device communicates over CAN bus, UART, USB, Bluetooth, or UDP/IP, the same protocol operates identically — only the link layer adapts to the specific transport medium. This allows firmware and host tools to treat all interfaces uniformly.
The stack is split into two configurable layers:
| Layer | Purpose | Configured by |
|---|---|---|
| Link layer | Datagram framing, addressing, and physical interface parameters (speed, timing, address bit allocation) | msgconf |
| Protocol layer | Service protocol enable/disable and SID remapping | protoconf |
Both layers are configured per-interface and stored in non-volatile memory (persistent across firmware updates).
The siliXcon protocol stack is the default topology. On request, a custom protocol can be implemented instead on a per-application basis (ModBus, ModBus/TCP, OBD/OBDII, CANOpen, CAN Aerospace, DeviceNET, DroneCAN, ...).
Protocol layer — service protocol
The system provides a proprietary service protocol to interact with the device. This protocol has been designed for low-latency, connection-less reliable data probing, configuring and upgrading in-application. It comprises a series of processes operating within the device, which are by default connected to all communication interfaces. The service protocol operates independently of the physical interface, allowing it to be connected to multiple communication interfaces at the same time. It does not depend on any item description files or object definitions — the device-specific data model is dynamically loaded from the device during runtime.
Service list
| Bit | SID | Service | Description | Used by |
|---|---|---|---|---|
| 0 | 0 | PWR (power) | Controls device power state (on/off/restart) and debugging output | term, emGUI, yosctl, bl_srm |
| 1 | 2 | FWD (forward) | Forwards messages between interfaces for indirect connectivity | msg_fwd interface driver |
| 2 | 4-5 | BL (bootloader) | Reads, erases, writes and configures firmware | bl_srm |
| 3 | 3 | ID (identification) | Transfers device metadata (HWID, SWID, UUID, ...) | auth, emGUI, yosctl, bl_srm |
| 4 | 6-7 | FS (filesystem) | Filesystem transfer | emGUI, yosctl |
| 5 | 8-9 | RPC (remote procedure call) | Executes commands in the device | emGUI, yosctl |
| 6 | 10-11 | STREAM (ASCII environment) | Standard input/output streaming | term |
| 7 | 20-22 | PLOT (scope) | Real-time data sampling and logging | scope |
The "Bit" column corresponds to the bit position in the protoconf enable/remap bitmask.
Service enabling and disabling
Each service can be independently enabled or disabled per interface using the protoconf command. A disabled service will neither transmit nor respond to incoming messages on that interface.
This allows restricting which protocols are reachable over a particular bus. For example, disabling the BL (bootloader) service on an external-facing interface prevents unauthorized firmware updates over that bus.
SID remapping
SID remapping requires YOS >= 2.8.5, BL (embl) >= 2.9.0, and SWTools >= 4.0.0.
By default, each service protocol uses a well-known SID (see table above). With SID remapping, a computed offset is added to all remapped services on the configured interface. The offset is derived from the protoconf configuration word as:
SID_offset = base << shift
Where base is bits 16-23 and shift is bits 24-31 (clamped to 0-31) of the configuration word.
This encoding allows small offsets to be expressed directly (shift = 0, offset = base, range 0-255) while also supporting much larger offsets when needed (e.g. base = 1, shift = 10 gives offset = 1024).
The effective SID for a remapped service becomes:
effective_SID = SID + SID_offset
On interfaces where SID maps to a bus identifier (e.g. CAN ID), the offset shifts all occupied identifiers accordingly. See CAN bus link layer below for the full CAN ID formula.
SID remapping is useful for:
- Avoiding SID collisions when a device shares a bus with other non-siliXcon equipment
- Relocating service protocol CAN IDs away from application-specific message ranges
- Gateway setups where multiple protocol stacks coexist
The remap offset may also be used by application-level modules, such as the driver API protocol (process protocol), to relocate their own SIDs consistently with the rest of the stack.
When SID remapping is active on the device, a matching device configuration file must be provided to the host-side tools so they use the same relocated SIDs. See the protoconf command reference for configuration examples and the swtools.ini format.
Protocol layer — process (application) protocol
Process communication protocol is another set of running services in the YOS device. It is used for sending device's internal state variables (such as motor voltages, currents or control inputs) out via desired communication interfaces. It can be also used for setting parameters and sending commands for the process control during device normal operation. This feature is optional and can be turned on / off on request; in most firmware branches is turned off by default.
Process protocol is application specific. Nevertheless, siliXcon usually implements set of services that standardizes the following:
- Driver block : Driver internal states (such as voltages, currents or speed) can be sent out from YOS device. Parameters and commands can be issued.
- Common I/O block : states of control inputs and outputs (such as throttle, brake or buttons) can be sent out of YOS device. Parameters and commands can be issued.
The process communication protocol is described in detail in the corresponding utility/driver manual.
Link layer
Every communication interface defines a link layer that encodes addressing and service identification into the interface-specific frame format. A message is the basic communication block — all interfaces translate to a standardized format with the following segments:
- Sender address — identifies the originating device on the bus (for unicast and multicast)
- Receiver address — identifies the target device (for unicast and hidecast)
- Service ID (SID) — selects which service protocol handles the message
- Flags / message type
- Payload
Device address
Each device has its own address. This address is common for all communication interfaces — it is a logical, link-level address of device, not address of communication interface. By default, address of each device is set to 0, it can be changed by command setaddr. Change of address takes place after reboot.
Datagram types
The datagram type determines routing behavior:
| Datagram type | Sender address | Receiver address | Delivery |
|---|---|---|---|
| Broadcast | not included | not included | All devices, raw frame |
| Multicast | included | not included | All devices, decoded |
| Unicast | included | included | Single target device |
The physical encoding of these fields varies by interface. Link-layer parameters (speed, timing, address bit allocation) are configured per-interface with the msgconf command.
CAN bus
On CAN bus, the CAN ID encodes both the sender address and the SID. The receiver address (for unicast) is carried in the first data byte.
CAN_ID = (SID << n) + sender_address
Where n is the number of bits allocated for the sender address (default n = 3, configurable via msgconf).
| CAN ID bits | Content |
|---|---|
| 0 to n-1 | Sender address |
| n to 10 (standard) or 28 (extended) | SID |
With the default n = 3, up to 8 devices can share a CAN bus, and each SID occupies a block of 8 consecutive CAN IDs.
When SID remapping is active, the remapped SID is used in the CAN ID formula:
CAN_ID = (effective_SID << n) + sender_address
= ((SID + (base << shift)) << n) + sender_address
= (SID << n) + (base << (shift + n)) + sender_address
To send a message with SID 24 from address 5 (n = 3):
CAN_ID = (24 << 3) + 5 = 197 = 0xC5
For a complete table of CAN IDs occupied by the service and process protocols, see What CAN IDs are occupied?. For the full CAN frame structure (unicast vs. multicast data bytes), see CAN Bus Link Layer.
CAN ID / SID offset calculator
Use this calculator to derive the SID offset base and shift from a known CAN ID, or compute the CAN ID from SID, offset base, offset shift, address, and the number of CAN address bits.
0x0SID offset = 0x000 >> 30, 0, 0, 0protoconf encoding: base (cfg2) = 0, shift (cfg3) = 0 (0 << 0 = 0)UART (UMSG)
On UART interfaces, the YOS communication system uses the UMSG protocol. Because UART is a point-to-point (1:n) connection, the sender address is implicit and not transmitted. Instead, the link-layer fields are carried inside the UART frame payload:
| Payload byte | Content |
|---|---|
| 0 | SID |
| 1 | Receiver address |
| 2+ | Message payload |
The UMSG transport layer adds framing (session byte, length, CRC) around the link-layer payload. For the full frame structure and implementation details, see UART Datagram Composition.
Other interfaces
Link-layer datagram composition for other supported interfaces (USB, Bluetooth, UDP/IP, LIN, SWD) is not publicly documented yet. Please contact siliXcon for detailed protocol descriptions of these interfaces.