⚡ Overview #
In modern smart grids and digital substations, IEC 61850 defines a standardized framework for high-speed, deterministic communication between Intelligent Electronic Devices (IEDs). Two of its most time-critical services—Sampled Values (SV) and Generic Object-Oriented Substation Events (GOOSE)—are collectively known as Fast Message Transmission Services (FMTS). These services operate directly at the Ethernet data link layer and demand strict real-time behavior.
A 2008 study by Dou Xiaobo et al. from Southeast University examined how FMTS can be implemented on VxWorks, Wind River’s widely deployed real-time operating system. The research highlights limitations of VxWorks’ default TCP/IP-centric networking model and introduces a Fast Communication Interface (FCI) to enable direct Ethernet access. This article rewrites and distills the paper’s core ideas for embedded and power-system engineers.
🔌 Why FMTS Is Challenging on VxWorks #
VxWorks is popular in power-system IEDs due to its:
- Deterministic, preemptive scheduler
- Low interrupt latency and fast context switching
- Modular and scalable kernel design
However, its standard networking stack is optimized for TCP/IP socket-based communication, which introduces unnecessary overhead for FMTS. IEC 61850 explicitly maps SV and GOOSE services directly to Layer 2 Ethernet, bypassing transport and network layers altogether.
FMTS encompasses several services, including multicast and unicast SV, GOOSE send/read, and GSSE variants. In practice, the study focuses on two representative cases:
- SV Multicast (SMM) – continuous transmission of sampled measurement data
- GOOSE Send (SGM) – rapid event notification with retransmission
Both rely on multicast or broadcast Ethernet frames, ASN.1/BER encoding, and strict validation rules.
🧩 FMTS Communication Model #
Abstract Communication Service Interface (ACSI) #
The ACSI defines IEC 61850 services independently of operating systems and protocols. FMTS uses a publisher/subscriber model:
- Publishers acquire data, encode it, and multicast frames
- Subscribers receive, validate, and refresh internal buffers
Key differences between SV and GOOSE include:
- SV: Fixed sampling intervals, no retransmission, validation via sample counters
- GOOSE: Flexible datasets, cyclic transmission with rapid bursts on state changes, validation via state and sequence numbers
In both cases, publishers construct APDUs/ASDUs, while subscribers perform integrity and freshness checks.
Specific Communication Service Mapping (SCSM) #
The SCSM maps ACSI services to concrete protocols. For FMTS, this mapping is a direct Ethernet binding:
- SV → Sampled Value (SAV) frames (IEC 61850-9-1, based on IEC 60044-8)
- GOOSE → GOOSE Protocol Data Units
This design eliminates higher-layer latency but requires explicit access to the data link layer.
🛠️ Fast Message Implementation on VxWorks #
VxWorks follows an OSI-inspired architecture but introduces a Multiplexing Interface (MUX) between network drivers and upper-layer protocols. Normally, applications interact through sockets, but FMTS requires bypassing this path.
Fast Communication Interface (FCI) #
The proposed FCI provides a controlled bridge between application tasks and the MUX layer. It consists of application-facing APIs and MUX callbacks:
- fciOpen – Registers the FCI with the MUX using
muxBind, specifying callbacks, protocol identifiers, and device context - fciMCastAddrSet – Configures multicast MAC addresses
- fciSend – Transmits raw Ethernet frames containing FMTS APDUs
On the receive side, MUX callbacks copy and parse frames, then notify application tasks via VxWorks semaphores. This approach enables deterministic, TCP/IP-free Ethernet communication.
Application Task Structure #
-
Publisher tasks
- Triggered by sampling interrupts
- Collect and buffer measurements
- Encode datasets into APDUs
- Queue frames in FIFO buffers and send via FCI
-
Subscriber tasks
- Validate incoming frames (sample counters or sequence/state numbers)
- Update datasets and application buffers
Task priorities and synchronization primitives are carefully chosen to minimize latency.
⏱️ Real-Time Processing Considerations #
Meeting IEC 61850 timing constraints—often in the microsecond to millisecond range—requires disciplined RTOS design:
- Assign highest priorities to FMTS-related tasks
- Use interrupt-driven data acquisition
- Minimize copying via FIFO queues
- Synchronize with lightweight semaphores
By avoiding the TCP/IP stack and operating directly at Layer 2, the FCI-based design achieves predictable timing.
🧪 Validation and Performance Results #
The study evaluated the implementation using a VxWorks-based IED emulator connected through an Ethernet switch:
- GOOSE round-trip latency: ~1 ms on average
- IEC 61850 requirement: ≤ 4 ms for critical protection events
- Stability test: 72 hours at 100 Hz with no frame loss
These results confirm that the proposed approach satisfies both performance and reliability requirements.
🌍 Ongoing Relevance #
Although published in 2008, this work remains highly relevant. IEC 61850 continues to evolve, and VxWorks is still widely deployed in utility automation. The paper provides a clear blueprint for implementing non-IP, real-time protocols on an RTOS by selectively bypassing conventional networking stacks.
The same principles apply today to industrial Ethernet, time-sensitive networking (TSN), and even real-time IoT systems—especially when deterministic behavior matters more than protocol generality.
For engineers working with IEC 61850 or real-time Ethernet: approaches like this remain essential for achieving true end-to-end determinism.