The document discusses the need for a long-term maintained industrial-grade embedded Linux platform, called the Civil Infrastructure Platform (CIP), to support critical infrastructure systems with lifetimes of 10-60 years. The CIP initiative aims to establish this platform by selecting a long-term supported Linux kernel and filling gaps between open source software capabilities and industrial requirements. It will provide reference implementations, trigger ecosystem development, and share maintenance costs between participating members.

1. Time is ready for the
Civil Infrastructure Platform
Agus%n Benito Bethencourt, Codethink
Noriaki Fukuyasu, The Linux Founda%on
1

2. 2
Our Civilization is Run by Linux
h%ps://www.airpano.com/360Degree-VirtualTour.php?3D=San-Francisco-USA

3. 3
h%ps://www.airpano.com/360Degree-VirtualTour.php?3D=San-Francisco-USA
Transport Energy Industry Others
Rail automa7on
Automa7c 7cket gates
Vehicle control
Power Genera7on
Turbine Control
Industry automa7on
Industrial communica7on
CNC control
Building automa7on
Healthcare
Broadcas7ng

4. 4
But there are issues to be
solved…
h%ps://www.airpano.com/360Degree-VirtualTour.php?3D=San-Francisco-USA

5. 5
Image: h%p://zdnet1.cbsistaKc.com/hub/i/r/2016/02/29/10863f77-89b2-40c0-9d8c-dbaa5feb65be/resize/770xauto/490141cef9bddc0db66b492698b53a50/powerplant.jpg
A Power Plants Controller:
20-60 years products life-cycle
with very reluctant nature for product update and upgrade of hardware and
base software platform

6. 6
A Railway System:
25-50 years products life-cycle
with, again, very reluctant nature for product update and upgrade of hardware
and base software platform

7. 7
We have a problem…

8. The Problems we face …
• The systems that support our modern civilization needs to
survive for a VERY long time.
• The systems not only have to survive for a long time, it has to be
robust, secure and reliable.
• It is a huge deal for those systems to stop the systems for
maintenance or replace.
8

9. The Solu7ons we need …
• Currently, the super long term maintenance has been done by each
individual companies.
• We need a framework to maintain one same open source based
system for many, many, many years to keep it secure, robust and
reliable.
9

10. 10 https://upload.wikimedia.org/wikipedia/commons/thumb/b/b7/Lorimerlite_framework.JPG/1280px-Lorimerlite_framework.JPG
What can we do make it happen?
And the answer was…

11. Civil infrastructure systems require
a super long-term maintained
industrial-grade embedded Linux plaLorm
for a smart digital future
11

12. Requirements for the Civil infrastructure systems
12
Industry
Grade
• Reliability
• FuncKonal Safety
• Security
• Real-Kme capabiliKes
Sustainability
• Product life-cycles of 10 –
60 years
ConservaKve
Upgrade/
Update
Strategy
• Firmware updates only if
industrial grade is
jeopardized
• Minimize risk of regression
• Keeping regression test and
cerKficaKon efforts low
This has to be achieve with …
Development 7me
§ Shorter development Kmes for
more complex systems
Maintenance costs
§ Low maintenance costs for
commonly uses sobware
components
§ Low commissioning and update
costs
Development costs
§ Don‘t re-invent the wheel

13. Railway Example
13
3 – 5 years development time
2 – 4 years customer specific extensions
1 year initial safety certifications / authorization
3 – 6 months safety certifications / authorization for follow-up releases
(depending on amount of changes)
25 – 50 years lifetime
Image: h%p://www.deutschebahn.com/contentblob/10862328/20160301+Stw+M%C3%BClheim+Innenansicht+1+(1)/data.jpg

14. Power Plant Control Example
14
3 – 5 years development time
0.5 – 4 years customer specific extensions
6 – 8 years supply time
15+ years hardware maintenance after latest shipment
20 – 60 years product lifetime
Image: h%p://zdnet1.cbsistaKc.com/hub/i/r/2016/02/29/10863f77-89b2-40c0-9d8c-dbaa5feb65be/resize/770xauto/490141cef9bddc0db66b492698b53a50/powerplant.jpg

15. Power plant runs on the Linux (please visit our booth)
15
MW
I P L P - A GE N E R AT OR
C V I V
H P L P - B
B oiler
T urbine
S peed Generator
Output
Valve pos ition/ dem and
s ig nal
Control Network
I/O Network
Duplex
System controller
・
・
・
Triple Redundant
Master controller

16. The evolu7on of civil infrastructure systems
Proprietary nature
§ Systems are built from the ground up for each
product
§ li%le re-use of exisKng sobware building blocks
§ Closed systems
Connected systems
§ Interoperability due to advances in machine-to-
machine connecKvity
§ StandardizaKon of communicaKon
§ Plug and play based system designs
Commodi7za7on
§ Increased uKlizaKon of commodity (open source)
components, e.g., operaKng system, virtualizaKon
§ Extensibility, e.g., for analyKcs
Stand-alone systems
§ Limited vulnerability
§ Updates can only applied with physical access to
the systems
§ High commissioning efforts
Technology changes
16

17. Things to be done: Crea7on of “Open Source Base Layer”
• Join forces for commodity components
• Ensure industrial grade for the operaKng system plakorm focusing
on reliability, security, real-Kme capability and funcKonal safety
• Increase upstream work in order to increase quality
and to avoid maintenance of patches
• Share maintenance costs
• Long-term availability and long-term support are crucial
• Innovate for future technology
• Support industrial IoT architectures and
state-of-the art machine-to-machine connecKvity
17
Open Source
Base Layer

18. 18
What is the CIP ini7a7ve doing

19. CIP key ac7ons
1. Establish an Open Source Linux based system that meets
the Industrial Grade requirements.
2. Fill the gap between capabiliKes of the exisKng OSS and
industrial requirements.
3. Provide reference implementaKons.
4. Trigger development of an emerging ecosystem including
tools and domain specific extensions.
19

20. Establish a FOSS Linux based system that meets the Ind. Grade req.
1. Select the first CIP kernel and iniKal maintainer
- 4.4 as first CIP kernel. Maintenance expected for above 10 years (SLTS).
- Ben Hutchings as iniKal CIP-kernel maintainer.
- Kernel maintenance policies (WIP).
2. Define iniKal board plakorms and provide support on CIP
kernel.
- Beaglebone Black and (RENESAS BOARD) as iniKal boards.
- BB upstream kernel support backported to CIP kernel.
20

21. Establish a FOSS Linux based system that meets the Ind. Grade req.
3. CIP kernel tesKng (WIP)
• Adapt kernelci.org project to CIP use case: board @ desk - single developer.
• kernelci VM to test kernels on a board connected to the dev. machine.
• Shared tests and logs.
• CIP kernel tested on Beaglebone Black.
• Add LAVA support to Fuego
4. Other
• KSPP patches backported to CIP-kernel.
• CIP whitepaper (WIP)
21

22. Civil Infrastructure PlaLorm aims to provide industrial grade soYware
Establish an open source “base layer” of industrial grade soYware to
enable the use and implementaKon in infrastructure projects of sobware
building blocks that meet the safety, reliability, security and
maintainability requirements.
• Fill the gap between capabiliKes of the exisKng OSS and industrial
requirements.
• Provide reference implementaKon
• Trigger development of an emerging ecosystem including tools and
domain specific extensions
è Ini7al focus on establishing long term maintenance infrastructure for
selected Open Source components, funded by par7cipa7ng membership
fees
CIP Reference Hardware
CIP Reference
Filesystem
image with SDK
CIP Kernel
User spaceKernel
Non-CIP packages
Any Linux distribuKon (e.g. Yocto
Project, Debian, openSUSE, etc.)
may extend/include CIP packages.
Hardware
Specifications DocumentaKon
Implement
22

23. Why maintaining old kernels?
1. Fear of regressions in newer kernels
(performance and system stability)
2. Reducing re-cerKficaKon costs and Kme by minimizing changes
3. Reduced number of kernel versions to be provided by SoC vendors
(like LSK or LTSI)
4. Serving as a common base for vendor-specific kernel forks
and out-of-tree code
(yes, we prefer upstreaming…)
23 see also h%p://lwn.net/ArKcles/700530/

24. Scope of ac7vi7es
User spaceKernel space
Linux Kernel
App container
infrastructure (mid-term)
App Framework
(opKonally, mid-term)
Middleware/Libraries
Safe & Secure
Update
Monitoring
Domain Specific communication
(e.g. OPC UA)
Shared config. & logging
Real-time support
Real-time /
safe virtualization
Tools Concepts
Build environment
(e.g. yocto recipes)
Test automation
Tracing & reporting
tools
Configuration
management
Device management
(update, download)
Func7onal safety
architecture/strategy,
including compliance
w/ standards (e.g., NERC
CIP, IEC61508)
Long-term support
Strategy:
security patch
management
Standardiza7on
collaboraKve effort with
others
License clearing
Export Control
Classifica7on
On device sobware stack Product development
and maintenance
Application life-
cycle management
Security
24

25. Target Systems
25
Out of scope:
• Enterprise IT and cloud system plakorms.
ARM M0/M0+/M3/M4
8/16/32-bit, < 100 MHz 32-bit, <1 GHz 32/64-bit, <2 GHz 64-bit, >2 GHz
n MiB flash n GiB flash n GiB flash n TiB flash/HDD
< 1 MiB < 1 GiB < 4 GiB > 4 GiB
Arduino class board Raspberry Pi class board SoC-FPGA, e.g.Zync industrial PC
ARM M4/7,A9,R4/5/7
Networked Node Embedded ServerEmbedded ComputerEmbedded Control Unit
special purpose & server based controllerscontrol systems
multi-purpose controllersPLC gateways
Sensor, field device
1 2 3 4
ARM A9/A35,R7,Intel Atom
… Device class no.
Architecture, clock
non-volatile storage
HW ref. platform
ARM offerings1)
RAM
application examples
ARM A53/A72,Core,Xeon
Intel offerings1)
M0/M0+/M3/M4 M4/7, A9, R4/5/7 ARM A9/A35, R7 ARM A53/A72
ARM M0/M0+/M3/M4 ARM M4/7,A9,R4/5/7 ARM A9/A35,R7,Intel Atom ARM A53/A72,Core,XeonQuark MCU Quark SoC Atom Core, Xeon
Target systems
Reference hardware for common sobware plakorm:
§ Start from working the common HW plakorm (PC)
§ Later extend it to small/low power devices
1 4 1) Typical configuraKons Q1/2016

26. 26
Next steps

27. Next steps by CIP
• Board @desk - Single dev
• Release kernelci VM and test CIP kernel in the open within CIP group.
• Increase test coverage.
• Define milestone 2.
• Kernel maintenance: define next steps.
• Analysis: select addiKonal sobware as part of CIP base system.
• CollaboraKon: kernelci.org, y2038, KSPP, RTL...
27

28. 28
Please Join us!

29. Why join CIP?
• Steer: parKcipate in project decisions and technical direcKon.
• Par7cipate: bring your use cases and ideas to the right forum.
• Learn:
• Collaborate:
29

30. Contact Informa7on and Resources
To get the latest informaKon, please contact:
• Noriaki Fukuyasu: fukuyasu@linuxfoundaKon.org
• Urs Gleim: urs.gleim@siemens.com
• Yoshitake Kobayashi: yoshitake.kobayashi@toshiba.co.jp
• Hiroshi Mine: hiroshi.mine.vd@hitachi.com
• Agussn Benito Bethencourt: agusKn.benito@codethink.co.uk
Other resources
• CIP Web site: h%ps://www.cip-project.org
• CIP Mailing list: cip-dev@lists.cip-project.org
• CIP Wiki: h%ps://wiki.linuxfoundaKon.org/civilinfrastructureplakorm/
• CollaboraKon at CIP: h%p://www.gitlab.com/cip-project
• CIP kernel: git://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-cip.git
30

31. Call for new par7cipants!
31
Provide a super long-term maintained industrial-
grade embedded Linux plakorm.
Platinum Members
Silver Members
Current members