Introducing the Civil Infrastructure Platform Yoshitake Kobayashi - PowerPoint PPT Presentation

Introducing the Civil Infrastructure Platform Yoshitake Kobayashi and Urs Gleim Embedded Linux Conference, San Diego, April 5, 2016 1

Definition Civil Infrastructure Systems are technical systems responsible for supervision, control, and management of infrastructure supporting human activities, including, for example,  Electric power generation  Energy distribution  Oil and gas  Water and wastewater  Healthcare  Communications  Transportation  Collections of buildings that make up urban & rural communities. These networks deliver essential services, provide shelter, and support social interactions and economic development. They are society's lifelines. 1) 1) adapted from https://www.ce.udel.edu/current/graduate_program/civil.html 2

The evolution of civil infrastructure systems Core characteristics Business needs Technology changes Industrial gradeness Maintenance costs Proprietary nature Commoditization  Reliability  Low maintenance costs  Systems are built from the  Increased utilization of for commonly uses ground up for each product commodity (open source)  Functional Safety software components components, e.g.,  little re-use of existing  Security operating system,  Low commissioning software building blocks  Real-time capabilities virtualization and update costs  Closed systems  Extensibility, e.g., for Sustainability analytics  Product life-cycles of Development costs 10 – 60 years Stand-alone systems Connected systems  Don‘t re -invent the wheel Conservative update strategy  Limited vulnerability  Interoperability due to advances in machine-to-  Updates can only applied  Firmware updates only if industrial Development time machine connectivity with physical access to the gradeness is jeopardized  Shorter development times  Standardization of systems  Minimize risk of regression communication for more complex systems  High commissioning efforts  Keeping regression test and  Plug and play based system certification efforts low designs 3

Things to be done • Join forces for commodity components • Ensure industrial gradeness for the operating system platform focusing on reliability, security, and functional 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 connectivity 4

Comparison with existing Alliances Other domains already benefit from collaborative development: drive instead of follow! • Development speed for shorter product cycles • High Software quality due to intense reviews and high test coverage Platform (Linus’s law) • Standard platforms enable ecosystems (e.g. for development tools, system extensions, new business models) Communication In many domains hosted by competing companies collaborate in alliances already. (GENIVI, for example) Consumer Industry 5

Civil Infrastructure Platform to provide software building blocks that support reliable transportation, power, oil and gas, and healthcare infrastructure Establish an open source “base layer” of industrial grade software to enable the use and implementation in infrastructure projects of software building blocks that Specifications Documentation meet the safety, reliability, security and maintainability requirements . • Share development effort for development of industrial grade bases systems. Non-CIP packages • Fill the gap between capabilities of the existing OSS and industrial requirements. Any Linux distribution (e.g. Yocto User space Project, Debian, openSUSE, etc.) • Reference-implementation consisting of may extend/include CIP packages. Implement • Specification of on-device software stack and tools infrastructure • Linux kernel, file system, etc. selected reference hardware CIP Reference Filesystem • Build environment and tools for companies to build their own distribution. image with SDK • Test framework and test cases Kernel • SDK and APIs CIP Kernel • Trigger development of an emerging ecosystem including tools and domain Hardware specific extensions. CIP Reference Hardware  Initial focus will be on establishing a long term maintenance infrastructure for selected Open Source components, funded by participating membership fees. 6

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

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

Relationship between CIP and other projects CIP will do not only Civil Infrastructure Platform development for CIP Member companies but also fund or … contribute to related upstream projects CIP source code • Import source code from Developers open source project or repositories Budget Developers from existing distribution to CIP CIP FTE’s member companies • Backport patches from upstream to CIP version Optional: funding of contribution selected projects CIP Super Long Collaborative Existing New CIP Term Support Existing projects Projects Existing project Project project / distro sub-project (unchanged) (e.g. RTL, Yocto, CII) Open source projects (Upstream work) Open source projects 9

Upstream first policy for implementation of new features All delta from mainline should be treated as technical debt. • No parallel source trees, directly discuss features in upstream projects. • Upstream first implementation. Take this to declared stable. • Then back-port to long-term support versions drive by CIP employee or CIP members. CIP members / CIP FTEs CIP members / CIP FTEs Project 1 Upstream new features (S)LTS backport Project 1 versions Project 2 Upstream new features new features (S)LTS Project 2 versions … 10

Super Long Term Support - Motivation About 3 months Kernel.org Upstream Kernel tree Approx. 2-5 years Long-term support （ LTS ） Backports bug fixes for 2 years Approx. 2-5 years Long-term support CEWG Initiative （ LTSI ） Add extra functionality on LTS for embedded systems and support it for 2 years 10 years – 15 years Every company, every project Backport of bug fixes and hardware support: the same work is done multiple times for different versions. 11 Release / Maintenance release

CIP kernel super long term support (SLTS) overview Approx. 3 months Kernel.org Upstream Kernel tree Approx. 2-5 years Long-term support （ LTS ） Backports bug fixes for 2 years Approx. 2-5 years Long-term support CEWG Initiative （ LTSI ） Add extra functionality on LTS for embedded systems and support it for 2 years Goal: 10 years – 15 years CIP super long-term CIP supported kernel Need to be maintained Approx. every 3 years more than 10 years After 5 years merge window for new Release / Maintenance release Backports, e.g. for SoC features will be closed, CIP kernel support reviewed by CIP changes focus to security fixes. 12