libIEC61850: a C implementation of the protocols behind the smart grid

What the library implements, and the four protocols in the list

libIEC61850 is an open-source GPLv3 implementation of an IEC 61850 client and server library implementing the protocols MMS, GOOSE, SV and R-Session. It is written in C according to the C99 standard, and the stated reason is to provide maximum portability, so it can be used to implement IEC 61850 compliant client and server applications on embedded systems and on PCs running Linux, Windows and MacOS. The protocol list in the features section is the scope in detail. MMS client and server. GOOSE, which is IEC 61850-8-1. Sampled Values, which is IEC 61850-9-2. And R-Session protocol support for R-GOOSE and R-SMV, again IEC 61850-8-1. That is the boundary of what the library does, and for a reader it is worth noting that the IEC 61850 standard family is larger than these four protocols.

The service surface, from data access to file services

Beyond the protocols, the features list describes the services a substation client or server needs. Support for buffered and unbuffered reports, and online report control block configuration. The data access service, get data and set data, and online data model discovery and browsing. All the data set services, get values, set values and browse, plus dynamic data set services for creating and deleting them. The log service, which comes with a flexible API to connect custom databases and a SQLite implementation, so a device or a simulator can persist events without committing to a database. MMS file services for browse, get file, set file and delete or rename file, which the documentation notes is required to download COMTRADE files, the waveform recordings an engineer actually wants from an incident. There is also setting group handling, support for service tracking, and GOOSE and SV control block handling.

Building the examples and running a server on Linux

The examples are built automatically when CMake is used, but the makefile route is documented separately and is the quicker one. In the project root you run make examples, and if the build succeeds you find the binaries in the project root along with a static library, libiec61850.a, in the build directory. You then run the sample applications from the example folders, for example cd examples/server_example_basic_io followed by sudo ./server_example_basic_io on the Linux command line, and the sudo is there because a server that opens raw sockets for GOOSE needs privileges. You can test the server examples with a generic client or with the provided client example applications. The examples directory listing shows how much surface there is, with goose_observer, goose_publisher, goose_subscriber, the SV example, the MMS utility, several client examples covering control, arrays, files, logging, async and no-thread variants, and R-GOOSE publisher and receiver examples.

make examples

cd examples/server_example_basic_io
sudo ./server_example_basic_io

TLS support, and the choice between two mbedTLS lines

The library has an implementation-agnostic interface for TLS configuration, and it currently ships with two implementations of that interface. One is mbedtls 2.28 LTS, which supports TLS versions up to TLS 1.2. The other is mbedtls 3.6.0, which supports TLS 1.2 and 1.3 only. Building against the first means downloading and unpacking mbedtls-2.28 into the third_party/mbedtls folder, with the note that when you download the source archive you have to rename the extracted folder to mbedtls-2.28, and then running make WITH_MBEDTLS=1. The 3.6 route is the same with a different flag, make WITH_MBEDTLS3=1. Under CMake both are automatic, the library builds with TLS support when the corresponding folder is present under third_party/mbedtls. The TLS support itself is IEC 62351-3 and 62351-4, the security standards layered on top of IEC 61850, and there is also a simple SNTP client for IEC 61850-5 that the documentation describes as being for testing purposes.

make WITH_MBEDTLS=1

make WITH_MBEDTLS3=1

The hardware abstraction layer, and why it is split by platform

The Makefile is where the library's structure becomes clearest, because the source directory list is the architecture. The MMS implementation is split into the ISO layers, iso_acse, iso_presentation, iso_session, iso_cotp, iso_mms with its server, client and common parts, plus iso_client and iso_server, and each of those pulls in an asn1c directory for the ASN.1 encoding. On top sit src/goose and src/sampled_values, and the IEC 61850 layer itself in src/iec61850 with client, common, server, and inside the server a model directory, an mms_mapping directory and an impl directory. The hal/ directory is the hardware abstraction layer, and it is split by platform with socket, thread, ethernet, filesystem, time, serial and memory subdirectories, one set for win32, one for linux and one for bsd, with the memory implementation shared. The GOOSE and sampled values sources sit behind an EXCLUDE_ETHERNET_WINDOWS conditional in the Makefile.

Windows GOOSE needs WinPcap, and that is a hard constraint

There is a whole build section for Windows with GOOSE support, and the reason is stated plainly. A third-party library, WinPcap, is required because current versions of Windows have no working support for raw sockets. The steps are: download and install WinPcap and make sure the driver is loaded at boot time, which is an option in the last screen of the installer, then reboot the system, or you can load the driver later but you need to reboot or load it before running any libIEC61850 applications that use GOOSE. Then download the WinPcap developers pack, unpack it, and copy the Lib and Include folders from the WpdPack directory into the third_party/winpcap directory of libiec61850. This is the sharpest platform constraint in the project, and it is the reason a Linux or embedded target is the comfortable deployment for the protocol features that matter most.

Installing the library, and the cmake route

The make and cmake build scripts both provide an install target, and it does something specific. It copies the API header files and the static library to a single directory, the headers into INSTALL_PREFIX/include and the static library into INSTALL_PREFIX/lib, and the reason given is that it makes integration into an external application easier since you only have to add a simple include directory to the build tool of your choice. The make invocation is make install, with the default install directory for the make build script being .install, and you can change it by setting the INSTALL_PREFIX environment variable, for example make INSTALL_PREFIX=/usr/local install, while for the cmake build script you provide the CMAKE_INSTALL_PREFIX variable instead. The cmake route on Linux is mkdir build, cd build, cmake .., make, with the build tools and cmake installed first, for example the build-essential and cmake packages on Ubuntu 20.04.

make install

make INSTALL_PREFIX=/usr/local install

Licensing, the language bindings and where the project stands

The licence arrangement is dual and worth understanding before you build a product on it. The library itself is open source under GPLv3, and for commercial projects, licences and support are provided by MZ Automation GmbH, with a contact address for licensing options. So the commercial route is a separate licence from the same vendor, not a support contract with a community. The bindings are the other thing to plan around, with C, C#/.NET and experimental Python APIs, the .NET documentation hosted separately from the C API documentation, and the Python bindings under a pyiec61850 directory and described as experimental. The repository also carries a dotnet/ directory, a fuzz/ directory, a demos/ directory and a tools/ directory, a sonar-project.properties for static analysis, a release_script.sh, and a .clang-format file. The default branch is v1.6_develop, the recent releases are v1.6.1 on 2025-07-31, v1.6.2 on 2026-07-23 and v1.6.2.1 on 2026-09-24, and the last push was on 2026-10-06.

Editorial conclusion

libIEC61850 suits a developer building an IEC 61850 client or server on embedded hardware, where the C99 implementation and the hardware abstraction layer matter, and who can work with a protocol stack in C. It is the wrong choice for a project that needs a managed protocol implementation with support obligations behind it, because the commercial route is a licence and support arrangement with MZ Automation, and a poor fit if you need more than the four protocols the library covers. Before adopting it, read the CHANGELOG and the API documentation linked from the README, and note that the Windows GOOSE path requires WinPcap because current Windows versions have no working raw socket support, which is a real constraint on that platform.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. mz-automation/libiec61850 on GitHub
3. Project website
4. README
5. Releases