Private meeting for Linux on Infrastructures · Embedded Linux Conference 2015 17 Target Layers L0...

Private meeting for Linux on Infrastructures

Embedded Linux Conference 201525 March 2015

2Embedded Linux Conference 2015

Meeting details: Date: 25 March 2015 (10am--12pm) Place: San Jose Marriott

Attendees (Alphabetical order) Noriaki Fukuyasu (Linux Foundation) Satoshi Ohshima (Hitachi) Urs Gleim (Siemens) Yoshitake Kobayashi (Toshiba)


Summarize of BoF Items need to be discussed

Project scopes to present for LF Board Memberd L1 and L2 are enough?

Lx is described in the next page

Development plans / items Based on BoF session and proposals

Need to more clarify for each companie’s requirement

Project name Milestones / Action items for next step

Agenda


Infrastructure Grade Linux (IGL) Industrial Infrastructure Initiative (I3) Industrial Infrastructure Platform (IIP) Infrastructure Linux Platform (ILP) Civil Infrastructure Platform (CIP) = Project code name for

now Civil & Industrial Infrastructure Platform (CIIP) Civil Automation Infrastructure Platform (CAIP) Open Industrial Alliance (OIA) Open Infrastructure Alliance (OIA) OpenINFRA

INFRAstructure ImplementatioN For Reliable A…??

Candidates for project name


Backups

Applying Linux to the Social Infrastructure BoF

Embedded Linux Conference 201523-25 March 2015

Noriaki Fukuyasu, Linux FoundationYoshitake Kobayashi, Toshiba


“Social Infrastructure Systems”?

The systems which are used to run our “Society”. This should include the systems such as:

- Entergy Infrastructure (Power Plants, Power Distributions)- Public Transportations (train, airports etc)- Road Management (toll gate management etc)- Earth monitoring- Communication Infrastructure

7


Today’ Goal Would like to share opinions with audience about the

“future” of social infrastructure systems (= SI systems) Would like to hear about the “requirements” for SI

systems. Would like to recruit companies/developers who want

to work with us in this area.


Typical SI systems today: STAND ALONE

sensorController(e.g. PLC)


Typical SI systems Future: CONNECTED

sensor

THE INTERNETOF THINGS

THE INTERNETOF THINGS

Controller(e.g. PLC)


Problem statement

The CONNECTED SI systems causes the following issues:

Security Safety

Functions


Problem statement

The CONNECTED SI systems causes the following issues:

Security Safety

Functions

The industry need to solve the issues if we wish to continue to use Linux for SI systems


What we want!

Same level of quality, security, safety, performance and functionality with connected environment.- Quality: Well tested- Security: Internet Security etc.- Safety: Certification- Performance: RT constrain - Functionality:

We want to maintain for a long time (more than 15 years).


Where we are at? Some companies already start working to try to

understand more about these issues, hoping to solve them collaboratively in a future.

The initial works are focused on:- Requirements Correction- Partner recruitment

Today we would like to share some of the results of our initial works.

14


Our Goal:

Develop REFERENCE IMPREMENTATION/META-DISTRIBUTION (*) for SI system collaboratively.

We are hoping to launch this project within CE Working Group at the Linux Foundation.

(*) Reference implementation/Meta-

Distribution may include:• Linux kernel and filesystem for

some target boards• Build tools/environments for

companies to build their own distributions for SI systems.

• Test-cases• Specification

The result of initial Study


Target Layers

L0 (Sensors, Actuators, PLC)Response time: L0-1 1-10us

L0-2 ： 10-100us

L1(Control Systems)Response time: 100us-10ms

L2 (Linux Servers)Server based controllers for specific purpose

Response time: 10ms-1s

L3Planning

L4 MES ： Manufacturing Execution System

ERP ： Enterprise Resource Planning

L5SoS ： System of System

Our target

• ICT system categorized in six layers• L3 layers and above should be implemented by

enterprise system• Network connected controllers which uses on

infrastructure systems

The system includes• Automation systems

• Controllers• PLC

• Microcontrollers• Signal controller

• Multi-purpose controller• Mini-server based controller

(includes PC based controller)• Sensor network systems


RequirementL2 L1 Plan

Security / Safety - White-List execution control- Log output

- Access Management (SE Linux/SMACK)

- One-Way gate way (Date Diode)

- Security in non-IP network - Security in IEC 611311-3

language

- Test cases for certification (EDSA, etc.)

Update - I/O card hot swap (CG Linux)- Failover in less than 100msec

- I/O card hot swap (CG Linux)- Failover in 5msec (with

memory tracking enabled)

- Dual node: CG-Linux- Single node: Live patching with

deterministic behavior

Real-time - 250usec - 1msec response time- 100msec network

communication frequency- Resource Management

(container)

- 100us-1ms (Hard-realtime)- 5 msec in Control frequency- Over 10 I/O cards, and 30K

in/out-puts

- Preempt RT patch / Hard realtime support / Test cases

Reliability - Compatibility test- 24/7 operation- Error detection

(CPU/Memory/BUS etc)- Error record (trace/Panic

Log/Crash dump)

- Compatibility test- 24/7 operation- Error detection

(CPU/Memory/BUS etc)- Error record (trace/Panic

Log/Crash dump)

- Framework for failure detection and recovery / Verification test

cases

Long-term Support - 7 years sales and 17 years maintenance

- Enable old Linux drivers- 2038 problem

- 12 years sales and 30 years maintenance

- Enable old Linux drivers- 2038 problem

- Very Long Term Supported (VLTS) distribution / VLTSI

kernel

Functional Safety - SILnLinux

Virtualization - HW update- Compatibility

- Full-system test

- L2: Might be able to use current VM technology

- L1: Very light weight VM / Container with RT capability /


Standards to work withRequirement for

standardsImplementation Kernel OSS Proprietary

softwareRemarks

IEC61131-3 Development environment, Execution

Engine

- UniSim(For Education) SIMATEC, Codesys

IEC61850 Kernel, Library, Hardware

- LibIEC61850 (C), OpenIEC61850(Java)

SISCO

IEC61970 (EMS, CIM,CIS)

Middleware, Hardware - NONE NONE

IEC62278 (RAMS) Development process - - -

IEC62280 Library, Application - OSS libraries (encryption, verification,

authentication) are used for implementation

ISO15745-4 (ADSNet)

Library, Application NX-dlink

IEC61508 SIL2 Development process SIL2LinuxMP (OSADL)

SIL2MPLinux is working in progress

IEC61508 SIL4 Development Process NONE

PROFINET HW(PROFINET IRT), Library, Application

NONE Usually, SDK is provided by device

vendor.


The tests required in SI Systems are including the followings:

Vulnerability (eg. Virus check) Performance Test

- Testing APIs as non-functional requirements

Conformance Test Install test Boot Test (Inc. APPs) Boot time (Inc. APPs) Run-Frequency (Inc. APPs) Devise driver test Heat-Run Test (with HW.) Compatibility Test Regression Test

Test

Free Discussion


We need to think “how the system as a whole can survive for 30yrs.” We need a guideline for it such as; Must be Open source Must be re-build every certain years. If the providers discontinued, the company must make the source codes available.

Communications b/w devises. Devise to devise, Devise to back-end

MW Communication OPC UA Domain specific APIs? Critical industrial standers

NER CIP

Long-Term Support Security patch management Distribution will help security management easier.


SCOPE Reference HW We want something we can build the whole stack. Start from working the common HW platform like PC and extend it to smaller/low power devises. “Rephrase” or re-define the layers. NI uses really different layer definition. We don’t cover Enterprise . We don’t cover small devise that Linux can’t run. We does not exclude devise management software back-end tools. We don’t cover the area the standard enterprise distribution can be used as it.

“Fill the GAP” between the existing Open source software and Industry requirements. Long Term Stability Contribute & Influence upstream projects.

Build with Yocto, Use a stable distribution.

For L2 we can use Red Hat/SUSE but we recommend to only use the components we define. Testing Infrastructure specific features need to be integrated in the platform.


Mile Stone to start the project Target Date: LinuxCon/ELCE in October 5th Companies should check the feasibility of the

schedule. Complete the slides of the project in Apr. 24th Urs will merge the slides of Kobayashi-san and

Siemens and propose it to the team by Apr 10. We are going to have another conf. call on Apr 10. Nori Fukuyasu will send invitation to the team within

next week. Based on the discussion on Apr 10, we will finalize the

deck we can all agree on by Apr 24th.


2015-

20162017

Mile Stone


Reference Platform

Reference Hardware

Kernel

Tool:• Yocto• Test

automation• Tracing• Config Mgt• Devise

Management

MW/Libraries

virtualization

• Functional Safety Architecture/Strategy

• Long Term Support Strategy

• Standardization needs to be Collaborative effort with others

RT Support

Safe & SecureUpdate

Monitoring

App Container Infrastructure = TBD

App Framework= TBD

Domain Specific communication (eg. OPC UA)

Shared config. & logging

Private meeting for Linux on Infrastructures · Embedded Linux Conference 2015 17 Target Layers L0...

Documents

Transcript of Private meeting for Linux on Infrastructures · Embedded Linux Conference 2015 17 Target Layers L0...