At the end of 2024, CIGRE Working Group B5.69 published Technical Brochure 949 — arguably the most comprehensive survey of real-world experience with IEC 61850-based protection and control systems using process bus. 55 projects, 195 reviewed publications, and a survey of 42 specialists from 29 organisations. An article by Rannveig Loken of Statnett (Norway) in PAC World Magazine summarises the key findings.
What the Survey Found
Of the 55 identified projects, roughly half are in operation — either pilot schemes with trip authority or serial deployments. 19 projects are at the stage of serial deployment. That number matters: process bus has moved past the enthusiast experiment phase.
{
"title": {
"text": "Project Types by Deployment Scenario",
"left": "center"
},
"tooltip": {
"trigger": "axis",
"axisPointer": {
"type": "shadow"
}
},
"grid": {
"left": "38%",
"right": "10%",
"top": "8%",
"bottom": "12%"
},
"xAxis": {
"type": "value",
"name": "Share of projects, %",
"max": 60
},
"yAxis": {
"type": "category",
"data": [
"Partial replacement (e.g. BCU only)",
"Full replacement of secondary systems",
"New bays (incl. substation expansion)",
"Other",
"New construction (greenfield)",
"Reconstruction (brownfield)"
],
"axisLabel": {
"width": 220,
"overflow": "break"
}
},
"series": [
{
"type": "bar",
"data": [
5,
5,
10,
22,
32,
52
],
"label": {
"show": true,
"position": "right",
"formatter": "{c}%"
},
"itemStyle": {
"color": {
"type": "linear",
"x": 0,
"y": 0,
"x2": 1,
"y2": 0,
"colorStops": [
{
"offset": 0,
"color": "#1B3D5E"
},
{
"offset": 1,
"color": "#2E6DA4"
}
]
}
}
}
]
}
The number of projects accelerated noticeably after 2018 — driven by the availability of IEC 61850 Edition 2-compliant equipment and tools, and by growing interoperability experience across vendors.
Voltage levels range from 35 kV to 400 kV, with no clear correlation between voltage class and project type. 21 of the 33 projects described in detail include multi-vendor interoperability requirements: protection IEDs from different manufacturers, merging units (MUs) from different vendors. Ethernet switches, by contrast, are typically sourced from a single supplier — interoperability is less of a concern there.
{
"title": {
"text": "Single-Vendor vs Multi-Vendor Solutions by Equipment Type",
"left": "center"
},
"tooltip": {
"trigger": "axis",
"axisPointer": {
"type": "shadow"
}
},
"legend": {
"data": [
"Multiple vendors",
"Single vendor"
],
"bottom": 0
},
"grid": {
"left": "32%",
"right": "8%",
"top": "8%",
"bottom": "15%"
},
"xAxis": {
"type": "value",
"name": "Number of projects (total 33)",
"max": 35
},
"yAxis": {
"type": "category",
"data": [
"Ethernet switches",
"SCU (station control unit)",
"BCU (bay control unit)",
"Merging units (MUs)",
"Full scope (BCU+SCU+MU+IEDs)",
"Protection IEDs"
]
},
"series": [
{
"name": "Multiple vendors",
"type": "bar",
"stack": "total",
"data": [
6,
6,
8,
10,
13,
17
],
"label": {
"show": true,
"position": "inside"
},
"itemStyle": {
"color": "#1B3D5E"
}
},
{
"name": "Single vendor",
"type": "bar",
"stack": "total",
"data": [
27,
27,
25,
23,
20,
16
],
"label": {
"show": true,
"position": "inside"
},
"itemStyle": {
"color": "#C0392B"
}
}
]
}
A telling detail: only in the protection IED category does multi-vendor supply come close to matching single-vendor (17 projects vs 16). In every other category — MUs, BCUs, SCUs, Ethernet switches — the overwhelming majority of projects use equipment from a single manufacturer. This confirms that multi-vendor protection is often driven not by technical necessity but by internal procurement policy: the long-standing practice of sourcing redundant protection sets from different vendors.
Economics: More Complex Than It Looks
CIGRE distinguishes economic from non-economic drivers. On the economic side, the picture is nuanced.
{
"title": {
"text": "Economic Drivers for Process Bus Implementation",
"left": "center"
},
"tooltip": {
"trigger": "axis"
},
"grid": {
"left": "8%",
"right": "8%",
"top": "15%",
"bottom": "20%"
},
"xAxis": {
"type": "category",
"data": [
"Reduction in procurement costs",
"Reduction in installation costs",
"Reduction in O&M costs",
"Reduction in TCO (incl. replacement)",
"Other"
],
"axisLabel": {
"interval": 0,
"rotate": 0,
"width": 120,
"overflow": "break"
}
},
"yAxis": {
"type": "value",
"name": "Share of respondents, %",
"max": 90
},
"series": [
{
"type": "bar",
"data": [
{
"value": 33,
"itemStyle": {
"color": "#A8CBE8"
}
},
{
"value": 63,
"itemStyle": {
"color": "#2E6DA4"
}
},
{
"value": 65,
"itemStyle": {
"color": "#2E6DA4"
}
},
{
"value": 73,
"itemStyle": {
"color": "#1B3D5E"
}
},
{
"value": 33,
"itemStyle": {
"color": "#8A8A8A"
}
}
],
"label": {
"show": true,
"position": "top",
"formatter": "{c}%"
}
}
]
}
The components themselves — MUs, LPITs, switches, cybersecurity equipment — are not yet cheaper than conventional equivalents. Savings emerge at other stages: engineering, installation, operation, and diagnostics. Some projects reported lifecycle cost savings of up to 30%. But that figure is achievable with serial deployment and standardised solutions. A single pilot is unlikely to show a positive economic case.
Among non-economic drivers, more than 50% of respondents cited flexibility, safety, reduction of outage time, and R&D opportunity.
{
"title": {
"text": "Non-Economic Drivers for Process Bus Implementation",
"left": "center"
},
"tooltip": {
"trigger": "axis",
"axisPointer": {
"type": "shadow"
}
},
"grid": {
"left": "33%",
"right": "12%",
"top": "8%",
"bottom": "10%"
},
"xAxis": {
"type": "value",
"name": "Share of respondents, %",
"max": 80
},
"yAxis": {
"type": "category",
"data": [
"Other",
"Environmental reasons",
"Asset management",
"Company image and recognition",
"Staff competence development",
"Possibility of LPIT application",
"Reduction of outage time",
"R&D",
"Safety/security",
"Additional functionality",
"Flexibility"
]
},
"series": [
{
"type": "bar",
"data": [
{
"value": 12,
"itemStyle": {
"color": "#8A8A8A"
}
},
{
"value": 33,
"itemStyle": {
"color": "#2E9E44"
}
},
{
"value": 42,
"itemStyle": {
"color": "#2E9E44"
}
},
{
"value": 46,
"itemStyle": {
"color": "#2E9E44"
}
},
{
"value": 46,
"itemStyle": {
"color": "#2E9E44"
}
},
{
"value": 48,
"itemStyle": {
"color": "#2E9E44"
}
},
{
"value": 52,
"itemStyle": {
"color": "#2E9E44"
}
},
{
"value": 52,
"itemStyle": {
"color": "#2E9E44"
}
},
{
"value": 55,
"itemStyle": {
"color": "#2E9E44"
}
},
{
"value": 55,
"itemStyle": {
"color": "#2E9E44"
}
},
{
"value": 64,
"itemStyle": {
"color": "#1B3D5E"
}
}
],
"label": {
"show": true,
"position": "right",
"formatter": "{c}%"
},
"markLine": {
"data": [
{
"xAxis": 50
}
],
"lineStyle": {
"color": "#E74C3C",
"type": "dashed"
}
}
}
]
}
The R&D item is worth dwelling on — 52% of respondents, more than half. For a network utility where R&D is not a core activity, this is not about inventing something new. It is about building internal expertise before the technology becomes mandatory. A pilot project delivers things that cannot be obtained any other way: hands-on engineering experience that transforms an organisation from one that trusts its contractor to one that knows what to specify and how to verify; real-world knowledge of interface problems between different vendors' equipment that lab tests and specifications will never reveal; draft internal standards, job descriptions, and training programmes, without which mass deployment becomes crisis management; a place where engineering, commissioning, and operations teams can see and work with the technology rather than learning from slides. In this sense, R&D in the context of a network utility is a strategic investment in the organisation's future ability to work with the technology — not a cost line without an obvious economic justification.
Barriers: People, Not Technology
The most instructive section of the survey is the obstacles. Technical issues — MU latency, GPS reliability, compatibility with future editions of the standard — are mentioned. But the dominant barriers are of a completely different kind.
{
"title": {
"text": "Barriers to Process Bus Implementation",
"left": "center"
},
"tooltip": {
"trigger": "axis",
"axisPointer": {
"type": "shadow"
}
},
"legend": {
"data": [
"Critical (≥60%)",
"Significant (35–59%)",
"Moderate (<35%)"
],
"bottom": 0,
"itemStyle": {}
},
"grid": {
"left": "37%",
"right": "12%",
"top": "8%",
"bottom": "15%"
},
"xAxis": {
"type": "value",
"name": "Share of respondents, %",
"max": 95
},
"yAxis": {
"type": "category",
"data": [
"Other",
"Missing business case",
"Regulatory requirements",
"Economic aspects",
"Cybersecurity",
"Internal acceptance of new solutions",
"Data modeling",
"Industrial deployment after pilot",
"Organizational and process adaptation",
"Engineering tools",
"Testing and diagnostic tools",
"Changes in O&M methods",
"Staff training and competencies"
]
},
"series": [
{
"type": "bar",
"data": [
{
"value": 10,
"itemStyle": {
"color": "#8A8A8A"
}
},
{
"value": 10,
"itemStyle": {
"color": "#8A8A8A"
}
},
{
"value": 14,
"itemStyle": {
"color": "#8A8A8A"
}
},
{
"value": 16,
"itemStyle": {
"color": "#8A8A8A"
}
},
{
"value": 28,
"itemStyle": {
"color": "#8A8A8A"
}
},
{
"value": 36,
"itemStyle": {
"color": "#E67E22"
}
},
{
"value": 36,
"itemStyle": {
"color": "#E67E22"
}
},
{
"value": 38,
"itemStyle": {
"color": "#E67E22"
}
},
{
"value": 46,
"itemStyle": {
"color": "#E67E22"
}
},
{
"value": 66,
"itemStyle": {
"color": "#C0392B"
}
},
{
"value": 69,
"itemStyle": {
"color": "#C0392B"
}
},
{
"value": 76,
"itemStyle": {
"color": "#C0392B"
}
},
{
"value": 78,
"itemStyle": {
"color": "#C0392B"
}
}
],
"label": {
"show": true,
"position": "right",
"formatter": "{c}%"
}
},
{
"name": "Critical (≥60%)",
"type": "bar",
"data": [],
"itemStyle": {
"color": "#C0392B"
}
},
{
"name": "Significant (35–59%)",
"type": "bar",
"data": [],
"itemStyle": {
"color": "#E67E22"
}
},
{
"name": "Moderate (<35%)",
"type": "bar",
"data": [],
"itemStyle": {
"color": "#8A8A8A"
}
}
]
}
Shortage of testing and commissioning tools. The need to train staff who are already overloaded and unavailable for training. Organisational resistance. The need to redesign internal processes and standards. The main brake is not hardware — it is a cultural shift. Moving from copper cables to Ethernet networks requires a different mindset, different skills, and a different way of organising work.
This sounds abstract until you face a concrete situation: a commissioning team arrives on site with no SV stream analyser and no understanding of how to check GOOSE subscription configurations without the familiar secondary-circuit voltmeter.
Which CIGRE Recommendations Are Universally Applicable
Several recommendations from TB 949 are directly relevant regardless of geography.
Do not transpose traditional standards onto digital systems — write new ones designed from the ground up for process bus. Standard design solutions, testing methods, operational documentation — all need to be written fresh, not adapted from the copper-cable world.
Assess economics over a programme horizon, not a single project. A single process bus installation will almost always cost more than a conventional one. Economic benefit emerges with serial deployment: standardised solutions, configuration templates, repeatable test procedures. An assessment of "expensive" based on one pilot is a methodological error.
{
"title": {
"text": "Project Types by Deployment Scenario",
"left": "center"
},
"tooltip": {
"trigger": "axis",
"axisPointer": {
"type": "shadow"
}
},
"grid": {
"left": "38%",
"right": "10%",
"top": "8%",
"bottom": "12%"
},
"xAxis": {
"type": "value",
"name": "Share of projects, %",
"max": 60
},
"yAxis": {
"type": "category",
"data": [
"Partial replacement (e.g. BCU only)",
"Full replacement of secondary systems",
"New bays (incl. substation expansion)",
"Other",
"New construction (greenfield)",
"Reconstruction (brownfield)"
],
"axisLabel": {
"width": 220,
"overflow": "break"
}
},
"series": [
{
"type": "bar",
"data": [
5,
5,
10,
22,
32,
52
],
"label": {
"show": true,
"position": "right",
"formatter": "{c}%"
},
"itemStyle": {
"color": {
"type": "linear",
"x": 0,
"y": 0,
"x2": 1,
"y2": 0,
"colorStops": [
{
"offset": 0,
"color": "#1B3D5E"
},
{
"offset": 1,
"color": "#2E6DA4"
}
]
}
}
}
]
}
Start training before large-scale deployment, not in parallel with it. CIGRE recommends concentrating projects in a single region so that operations staff accumulate experience rather than learning the technology from scratch on each new site.
Preserve knowledge within the organisation. CIGRE explicitly identifies this as a knowledge conservation policy — a systematic approach to ensuring that digitalisation experience does not leave with specific individuals. In practice: document not only "what was done" but "why this approach"; maintain standard solutions and templates accessible to all engineers; run mentoring and paired working between experienced and junior staff. An organisation where process bus competence is concentrated in two or three individuals risks losing the ability to operate its own systems if they leave.
Invest in commissioning and diagnostic tools. A toolkit for testing digital interfaces, fault-finding tools for operational use, and methods for working with SCD files to automate verification checks. Without this, neither training nor serial deployment can function.
And separately on factory acceptance testing (FAT). Digital process bus interfaces allow the bulk of verification to be completed before going to site — one of the concrete, measurable advantages worth exploiting.
In Summary
55 projects worldwide, some of which have been operating for more than five years. Up to 30% lifecycle cost savings with a serial approach. Barriers that lie not in technology but in organisation and competence.
TB 949 is not a theoretical document. It is a catalogue of mistakes that others have already paid for. It makes sense to learn from them.