FLYNC Examples¶

Welcome to the configuration examples and tutorials! This section walks you through practical usage of the FLYNC configuration system with real examples.

Base Example¶

This example provides a fully functional reference configuration that can be used as a baseline when developing your own system setup. It demonstrates how multiple networking features can be integrated into a cohesive design, helping you understand both structure and implementation details.

The configuration includes the following key components:

Ethernet Network Topology - Illustrates how devices are interconnected, including port roles, link relationships, and overall network structure. This serves as a guide for designing scalable and deterministic Ethernet architectures.
Time Synchronization - Shows how gPTP configuration is defined and maintained across the network.
MACsec - Shows the configuration of MACsec-aware nodes of the system for link protection.
Quality of Service (QoS), Layer 2 TSN, and TCAM Usage - Provides sample configurations for traffic prioritization and deterministic networking using Time-Sensitive Networking (TSN) features. It also illustrates how TCAM rules can be allocated and used for traffic classification and filtering. You can use this configuration as a starting point, adapting interface mappings, policies, and feature parameters to match the specific requirements of your hardware platform and application.
Network Management (NM) - Shows how an NM message is modelled vendor-neutral as an ordinary PDU with ordinary signals, tagged via the pdu_usage / frame_usage fields, and bound to both Ethernet and CAN transports.
Signals, PDUs and CAN Communication - Shows how bus-agnostic signals are grouped into PDUs and carried by CAN and CAN FD frames, and how the same PDUs are packed into Ethernet container PDUs.

Example Configuration¶

Find an example configuration directly in github.

Ethernet Network Topology¶

The Ethernet Network Topology diagram provides a comprehensive visual representation of all components included in the configuration.

The diagram identifies the VLANs, IP addresses, and multicast groups assigned to each controller and switch, giving a complete view of the logical network segmentation and addressing scheme.

Each of the four ECUs is shown as an individual block. The diagram also illustrates the internal connectivity between components within each ECU, as well as the external connections between ECUs, making both intra-ECU and inter-ECU communication paths easy to understand.

QoS/L2 TSN and TCAM Configuration¶

The QoS / Layer 2 TSN and TCAM Configuration diagram provides a comprehensive visual overview of the Time-Sensitive Networking (TSN) mechanisms and TCAM rules implemented in this configuration.

The diagram highlights the HTB (Hierarchical Token Bucket) shaper configured on the Linux-based controllers (eth_ecu), as well as the Credit-Based Shapers (CBS) applied on the egress ports of the switches to manage time-sensitive traffic.

It also shows the ingress stream filters deployed on the ingress ports of the switches, which are used for traffic policing and stream identification in accordance with TSN requirements.

In addition, the diagram includes the TCAM rules configured on the switch (z2_switch1), illustrating how hardware-based classification and filtering are used to enforce traffic handling policies.

Time Synchronization Configuration¶

The Timesync Configuration diagram provides a clear visual overview of the time-synchronization roles assigned to all time-aware devices in the system.

It illustrates how time is distributed across the network, identifying which devices act as time-transmitters or time_receivers.

This helps clarify the synchronization hierarchy and the timing relationships between system components.

MACsec Configuration¶

The MACsec Configuration diagram provides a clear visual overview of the roles and relationships of all MACsec participants within the system.

It identifies which devices function as MACsec peers, showing where secure channels are established and how link-layer protection is applied across the network.

This helps clarify the security topology and illustrates how data integrity (and confidentiality) is maintained between connected nodes.

Further Examples¶

ECU Variants¶

Variant 1: Single controller, single (virtual) interface, external PHY¶

Find this example on github: ecu_variant_1.

_images/ecu_variant_1_single_controller_single_iface_ext_PHY.svg

Note

The MDI configuration must be compliant with that of the other ECU to which the port is connected to. In this case, mode, speed and duplex must match; while role must be opposite to that of the other ECU config (i.e., if slave in the connected ECU, master shall be configured).

Note

The MII configuration must be compliant with that of the ECU controller configuration. In this case, type and speed must match; while mode must oppose the controller interface config (i.e., if mac in the controller interface, phy shall be configured).

Variant 2: Single controller, single (virtual) interface, integrated PHY¶

Find this example on github: ecu_variant_2.

_images/ecu_variant_2_single_controller_single_iface_int_PHY.svg

Note

Since PHY is integrated into the host controller, no MII configuration is needed neither on the port side, nor on the controller side.

Variant 3: Single controller, multiple (virtual) interfaces, external PHY¶

Find this example on github: ecu_variant_3.

_images/ecu_variant_3_single_controller_multiple_iface_ext_PHY.svg

Variant 4: Single controller, multiple (virtual) interfaces, integrated PHY¶

Find this example on github: ecu_variant_4.

_images/ecu_variant_4_single_controller_multiple_iface_int_PHY.svg

Variant 5: Single controller, single (physical) interface, external PHY, Multiple VMs¶

Find this example on github: ecu_variant_5.

_images/ecu_variant_5_single_controller_single_iface_multiple_vms.svg

Note

If there is a VM, it needs to tie to a Controller Interface through a Virtual Switch.

Variant 6: Single controller, multiple (physical) interface, external PHY no VMs, Virtual Switch¶

Find this example on github: ecu_variant_6.

_images/ecu_variant_6_single_controller_multiple_iface_physical_ext_phy.svg

Note

Two controller interfaces might be connected through an Virtual Switch.

Variant 7: Switch ECU, multiple (virtual) interfaces, external PHY¶

Find this example on github: ecu_variant_7.

_images/ecu_variant_7_switch_ecu_ext_PHY.svg

Note

The MII mode of the switch1_port0 must oppose the one of the ecu1_controller1_iface1.

Variant 8: Switch ECU with Host controller, multiple (virtual) interfaces, external PHY¶

Find this example on github: ecu_variant_8.

_images/ecu_variant_8_switch_ecu_with_host_ext_PHY.svg

Note

The MII mode of the switch1_port0 must oppose the one of the ecu1_controller1_iface1.

Note

The Host controller of the switch will have the same configuration as any Controller Interface.

Variant 9: Single controller, single Ethernet interface and a CAN interface¶

Find this example on github: ecu_variant_9.

_images/ecu_variant_9_single_controller_eth_iface_can_iface.svg

Note

A single controller can host a CAN interface alongside its Ethernet interface. The Ethernet interface has its own ECU port and external PHY; the CAN interface instead joins a bus via bus_ref and lists the frames it exchanges through sender_frames / receiver_frames.

Note

Several CAN frames share the single BodyCAN bus. The frames are defined once on the bus under communication/channels/can/, and the CAN interface references them by their frame_ref (the CAN identifier).

Internal Topology (Configuration and Types)¶

The internal topology file of each configured ECU must contain the description of all the internal connections within the device. The FLYNC model supports the connection types present in the following picture:

Important

Be aware of the kind of connection that is added to the file, since the name of the components shall adjust to it accordingly.

Example file (dummy example)

Additional Security Features Configuration¶

Firewall Configuration¶

The Firewall model consists of a default action and three lists defining rules for input, output and forward traffic, respectively. Each of these rules contains a pattern the packets are matched against, and an action executed when this check is positive:

Switch TCAM Configuration¶

Sockets Configuration¶

A socket in FLYNC represents a logical endpoint on a virtual network interface of an ECU. It defines how the controller will send and receive traffic over a specific IP address, port, and protocol (TCP/UDP).

Note

Sockets must be defined in a separate folder for each ECU for better readability.

Note

Multiple sockets may be defined in a single file for different address endpoints, but they must belong to the same VLAN.

Signals¶

A Signal is the smallest data element in the FLYNC model: a single value with its bit length, optional linear scaling (factor / offset / unit) and limits, and an optional value_encoding that maps raw values to labels (text_table, bitfield_text_table or bitmask_flags). Signals are bus-agnostic and are placed into a PDU through a signal instance that fixes the bit_position and endianness.

_images/pdu_engine_status_signal_breakdown.svg

Note

Signals are defined inline inside the PDU that carries them, under communication/channels/pdus/.

PDUs¶

A PDU (Protocol Data Unit) is the container that groups signals for transmission. PDUs are defined independently of any bus and stored under communication/channels/pdus/ (Ethernet container PDUs live in communication/channels/ethernet_pdu_containers/). A frame, a socket, or another PDU then references a PDU by name.

Three PDU types are distinguished by the type discriminator:

standard - a non-multiplexed PDU carrying a flat list of signal instances.
multiplexed - a PDU with a selector_signal whose value selects which mux_groups block of signals is active on each transmission cycle.
container - a Container PDU that packs several other PDUs into one payload, each contained PDU prefixed by a per-slot header.

_images/pdu_types_standard_multiplexed_container.svg

Multiplexed PDU

PDU_TransmissionStatus multiplexes on the 4-bit GearInfoMux selector: selector value 0 activates the gear-position signals, value 1 the torque-converter signals.

📄 communication/channels/pdus/PDU_TransmissionStatus.flync.yaml

name: PDU_TransmissionStatus
type: multiplexed
length: 8
description: Transmission status, multiplexed on GearInfoMux selector.

selector_signal:
  bit_position: 0
  endianness: LE
  signal:
    name: GearInfoMux
    description: Multiplexer selector for TransmissionStatus PDU.
    bit_length: 4
    data_type: uint8

mux_groups:
  - selector_value: 0
    pdu:
      name: PDU_TransmissionStatus_Gear
      type: standard
      length: 8
      signals:
        - bit_position: 8
          endianness: LE

          signal:
            name: CurrentGear
            description: Currently engaged gear.
            bit_length: 8
            data_type: uint8
            value_encoding:
              type: text_table
              entries:
                - value: 0
                  label: Park
                - value: 1
                  label: Reverse
                - value: 2
                  label: Neutral
                - value: 3
                  label: Drive_D1
                - value: 4
                  label: Drive_D2
                - value: 5
                  label: Drive_D3
                - value: 6
                  label: Drive_D4
        - bit_position: 16
          endianness: LE

          signal:
            name: GearShiftMode
            description: Automatic / manual / sport shift mode.
            bit_length: 4
            data_type: uint8
            value_encoding:
              type: text_table
              entries:
                - value: 0
                  label: Automatic
                - value: 1
                  label: Manual
                - value: 2
                  label: Sport
  - selector_value: 1
    pdu:
      name: PDU_TransmissionStatus_Torque
      type: standard
      length: 8
      signals:
        - bit_position: 8
          endianness: LE

          signal:
            name: TorqueConverterSlipSpeed
            description: Slip speed of the torque converter.
            bit_length: 16
            data_type: uint16
            factor: 0.1
            offset: 0.0
            unit: rpm
        - bit_position: 24
          endianness: LE

          signal:
            name: TorqueConverterLockup
            description: Torque converter lock-up clutch state.
            bit_length: 2
            data_type: uint8
            value_encoding:
              type: text_table
              entries:
                - value: 0
                  label: Open
                - value: 1
                  label: Slipping
                - value: 2
                  label: Locked
                - value: 3
                  label: Error

Container PDU

EthPowertrainContainer bundles three application PDUs - PDU_EngineStatus, PDU_VehicleDynamics and PDU_TransmissionStatus - into one Ethernet payload. The per-slot header gives the bit widths of the PDU-ID and length fields, and each contained PDU declares its pdu_id and byte offset inside the container.

Note

The communication/channels/pdus/ directory is optional and may be omitted when no PDUs are defined.

CAN Buses¶

A CAN Bus carries frames between controllers. Each bus is stored in its own file under communication/channels/can/ and defines the bus-level parameters plus the full list of frames transmitted on it. Both classical CAN and CAN FD are supported by the same bus type: setting fd_enabled: true (together with an fd_baud_rate) permits can_fd frames with payloads up to 64 bytes and an optional bit-rate switch.

Each frame references its payload PDU by name via packed_pdus and may carry an optional timing block driving cyclic and event-driven transmission.

DiagCAN is a CAN FD bus (500 kbit/s nominal, 2 Mbit/s data phase). Its can_fd frames set bit_rate_switch and carry 64-byte diagnostic payloads. It also carries the Network Management frame documented in the NM example.

Which frames a controller sends and receives is declared on its CAN interface, one file per bus, where frames are referenced by bus_ref and their numeric frame_ref (the CAN ID). On DiagCAN, high_performance_compute sends the diagnostic-response and Network-Management frames and receives the diagnostic request:

Note

The communication/channels/can/ directory is optional and may be omitted when no CAN buses are defined.

Network Management (NM)¶

The example illustrates how vendor-neutral state management membership is configured around vehicle functions (AutonomousDriving, Comfort, …). Instead of per-node NM identity, each participant declares which function it contributes to, and several nodes may share the same function. The example spans Ethernet, CAN, and LIN within one vehicle-wide state management group, VEHICLE (see flync_4_nm for the model).

The NM message is modelled as an ordinary PDU (PDU_NmMessage) with ordinary signals:

sender_id (uint8) - identifies the sending node.
control_vector (uint8) - control bits of the NM message: repeat_message_request, sleep_ready, active_wakeup, and relevance_vector_present.
relevance_vector (uint32) - a relevance bitmask whose flags are vehicle functions (AutonomousDriving, OnlineCommunication, Comfort), not nodes. A participant references the function bit it contributes to; several ECUs may share the same function bit, and one ECU may reference several. The set of flags always matches the derived participant bits of this workspace.
user_data (bytearray, 2 bytes) - opaque OEM/application extension area.

Hint: This layout is one illustrative arrangement - FLYNC prescribes no NM PDU format. Each field is an ordinary signal at a configurable bit_position, so a workspace can reorder, resize or rename them (e.g. swap sender id and control vector) to match its stack.

The PDU is flagged pdu_usage: network_management regardless of which transport technology carries it.

State management group

The group registry lives in communication/state_management/groups.flync.yaml (with the reusable timing profiles in timing_profiles.flync.yaml); memberships are declared entity-side only. The workspace exercises every use case:

Use case	Where to look
Controller-level membership (recommended site); one ECU owning several function bits (`AutonomousDriving` + `OnlineCommunication`)	`ecus/high_performance_compute/controllers/hpc_controller2/state_memberships.flync.yaml`
ECU-level membership; several ECUs sharing one function bit (`Comfort`)	`ecus/zonal_gateway/`, `ecus/can_node_*/`
Bus-level membership - the LIN bus participates as one bit with no NM frame (master-as-proxy)	`communication/channels/lin/body_lin.flync.yaml`
Gateway use case - receives the NM PDU on Ethernet and forwards it onto BodyCAN via ordinary `sender_frames` (plain cross-bus forwarding)	`ecus/zonal_gateway/`
Switch use case - the switch-core controller observes the group	`ecus/zonal_platform2/controllers/z2_controller2/state_memberships.flync.yaml`
Derived proxy - `zonal_platform1` declares no membership itself; as BodyLIN’s master, validation derives it as the bus’s representative (it receives the group state on Ethernet and drives BodyLIN to sleep)	`zonal_platform1`

Ethernet NM

The VEHICLE NM PDU (PDU_NmMessage) is wrapped in an Ethernet Container PDU (eth_nm_container_a) and bound to a UDP socket via the pdu_sender / pdu_receiver deployment types:

Sender - high_performance_compute transmits the NM container multicast on VLAN 40, group 224.0.0.1, UDP port 1200, and also receives it via pdu_receiver so it can observe the group state.
Receivers - zonal_platform1, zonal_platform2, and zonal_gateway receive it via pdu_receiver sockets on the same VLAN and multicast group.

As an alternative way, the NM PDU (PDU_NmMessage) can be attached to a Ethernet Container PDU (available as example eth_nm_container_b) which does not carry a PDU Header, as header/id_length_bits & length_field_bits are configured with length zero (0), to be sent as a raw UDP payload as example Use-Case.

CAN NM

On BodyCAN, the VEHICLE group follows the classic CAN pattern: zonal_gateway feeds Frame_Nm_Gateway (forwarding the NM PDU from Ethernet onto BodyCAN), while can_node_1 / can_node_2 each transmit their own NM frame and receive the others. All three contribute to the Comfort function, so they share the Comfort relevance bit - requesting Comfort keeps them awake together, which is how CAN resolves NM state per function.

DiagCAN carries the vehicle NM PDU (PDU_NmMessage) in Frame_NmMessage, tagged frame_usage: network_management, sent by high_performance_compute - a second CAN bus of the same VEHICLE group. It is a plain diagnostics bus otherwise; it declares no membership of its own.

LIN NM

BodyLIN (the body bus - exterior mirrors and cabin ambient lighting) takes part through a bus-level membership: the whole bus joins the VEHICLE group as one participant on the Comfort function, without a LIN frame of its own. Its master (zonal_platform1) receives the group state on Ethernet (pdu_receiver) and drives the LIN bus to sleep with it; validation resolves the master as the bus’s representative automatically.