Theme 4: MBSE applied to computing platforms and energy management

Theme 4:

MBSE applied to computing platforms and energy management

This theme is especially concerned with energy efficient computing and includes the better management of large distributed networks of devices. UTSA has demonstrated considerable advances in this area, with recent research demonstrating considerable power savings for large cloud computing networks. The emphasis of this theme will be on the use of MBSE to describe, and hence design large networks that dynamically reconfigure. Environmental modelling will also be important in this theme.

Theme 4: workshop interpretations

Although originally focused on energy efficient computing, the theme was more broadly interpreted by both the EU and US workshops as covering the use of MBSE for energy efficiency.

This usefully brought in aspects of modelling associated with smart grid.

There were two workshops:

1. San Antonio, Tx, March 2016

2. Kongsberg, Norway, June 2016 (this was associated with the IEEE SoSE conference)

State of the Art Participant

Presentations

Click on image above to view pdf

Click on image above to view pdf

Click on image above to view pdf

Click on image above to view pdf

Click on image above to view pdf

Click on image above to view pdf

Formal Methods for a System of Systems Analysis Framework

Applied to Traffic Management

Prof C.E. Dickerson, Dr S. Ji and R. Roslan

16 June 2016

Standards (e.g.) DO-178C, FTA approaches focus on definition and structuring of faults.

Behaviour modelling can support the discovery of faults

Motivation

MBSE with SysML supports behaviour modelling; SysML is graphical but not formal

IEEE SoSE 2014: Ingram, Andrews, Payne and Plat

DO-178C: Software Considerations in Airborne Systems & Equipment Certification FTA: Fault Tree Analysis

MBSE: Model Based Systems Engineering SysML: Systems Modeling Language RMS: Ramp Meter System

RMS Fault

Traffic Light Faults

No light Light Stuck

on Green

Incorrect Rate

Calculation

Fails to adopt

Collaborative

Mode

Operational Faults

Light Stuck

on Red

Fails to exist

Collaborative

Mode 1 1 3

2 4 5

fUML philosophy: precision by attaching executable notation (Alf) to UML models where behaviours can be a step towards formalisation of graphical models

Klir general system methodology

Semantic transformation techniques

Dependency Structure Matrices (DSM)

Basis of Approach

Attach Mathematical Matrix Representations of Behaviour to SysML Graphical Models

fUML: Foundational Unified Modeling Language Alf: Action Language for fUML SysML: Systems Modeling Language

Organize the elaborated Use Case into an Activity Diagram to make a complete description of behaviour

The structure of flow and control of activities can now be represented by the adjacency matrix of the graphical model

Application to the Case Study: Behavior Modeling

Application to the Case Study: Matrix Representation

Potential fault: 5. The RMS calculates an incorrect rate for vehicles to be

admitted

A framework for associating precise semantics with SysML behavioural models • Model specifications are guided by semantic transformation

• Formal analysis is based on matrix representation

Sematic Transformation: Next Steps • Matrix representation of Class/Block Diagram, State Machines

• Transformation (functional allocation ) of Activities to Classes

• Which provides insight for component level faults identification

Conclusions and Future Work

Identification of gaps

• What are the main gaps in MBSE relevant to Theme 4? o Rationale for identifying the gap?

Topics: • Understanding how distribution affects QoS such as energy

• Distribution: choices – client host (single machine), client with centralised remote server, decentralised control architecture, cloud

• Computation with your MBSE model executables • Security, resource consumption, energy management, performance for analysis (tabulate

against distribution) • Can be used to identify gaps in MBSE (systematically exploring each cell of the table)

• Does MBSE make any of these easier to understand or introduce new challenges? • Bridge conceptual level models with detailed level simulations

• Bringing detailed energy management simulations into MBSE • Collaboration between engineering domains & interoperability between engineering tools

• E.g. mechanical/electrical/other engineering tools do not integrate with those used by systems engineers

• To use MBSE / SysML other engineers need to be systems engineers • Encipher-ment and interface for crypto analysis implementation; privacy

• IP protection • MBSE can offer more than it does offer, instead of identifying behaviour of system it can offer fault

identification indirectly • Different cultures/viewpoints for MBSE in US/EU/Asia (need adaptation to local culture)

Collated answers

• What advances in MBSE are required to address the gaps? Topics: 1. Ease understanding/comprehension/readability of models

1. Models can be difficult to understand / communicate (e.g. Alloy, (formal) semantics of SysML)

2. Need a balance between formality and comprehension of notations 3. Is a philosophy such as fUML sufficient (back to basics, more precise, executable aspects)?

2. Is MBSE as it is today suitable for SoS? Implication is increased complexity in computing

3. Adapt multiple viewpoints (enterprise, human, …)

1. Traceability from higher levels (government or legal) to more detailed levels of the system

4. Code generators for real implementations from models

5. Network technology may provide a way to fill the gap of systems goes to SoS goes to enterprise

6. What level of model detail is needed for different stages of the CPS lifecycle?

7. Formal methods are needed for enterprise architecture modelling and simulation 1. Driven by analysis needs

Outputs: Dream Projects Theme 4 EU workshop, 16th June, 2016 – Kongsberg, Norway

Chaired by: Zoe Andrews, Newcastle University

Collaboration opportunities ideas & votes

Participants post-it notes

Collaboration in regard of the enterprise culture / “DNA” / working practice differences –

Geographically distributed MBSE: How to do: - Sharing - Security - Handle: culture differences

& time differences

To have a medium for users and researchers & providers in exchanging experience & knowledge & room for improvement

“Understanding & supporting geographically disperse MBSE” – 5votes • Electrical vehicle +

smartgrid + network … IoT – 3votes

• Modelling + Simulation of manufacturing environmental focusing data management and IoT

Collaboration opportunity Model Interchange and Exchange Aim: Create a PLA/Meta model that could be used to better align … model Objectives • Review ... • PLA state of Art • Formal PLA Methods

US & EU Tool vendor Collaboration Project

“Tool interoperability/model exchange/interchange” – 8votes

Dream Projects

1) Transatlantic standardised guide for cross-cultural MBSE 2) US and EU collaboration on MBSE tool PLA Standard

Dream Project TransAtlantic standardised guide for cross

cultural MBSE Team members:

Aim, objectives &

application domain

of the project

• Unified standardised guide for MBSE

• Understand cultural differences and agree on commonalities

• Provide case studies in successful collaborations

(Desired) US

contribution • Share successful use cases from US (MBSE)

• Share failed case as well

(Desired) EU

contribution • Share –”- EU

Collaboration

instruments.

Enablers & barriers

to collaboration.

• People may not want to share failed cases (-)

• Motivation is too low (-)

• Workshops to enable collaboration (+)

• Share tools & data only accessible through

collaboration (+)

Why should the

US/EU fund this

project (as opposed

to an alternative

funder)?

• Enable EUs leadership

• Benefits to EU wide standardisation

Baseline state of

the art (key existing

technologies)

INCOSE handbook, MODAF, DODAF, TOGAF, OMG?

Related roadmap

elements

Developments in M&S (Gaps): 1; 3; 5; 6 Collaboration opportunities:

Dream Project US & EU Collaboration on MBSE Tool PLA

Standard

PLA = software Product Line Architecture Team members:

Aim, objectives &

application domain

of the project

Aim: To create a formal PLA meta-model that could be used for international or industry standard to improve

MBSE tools for M&S

Objectives:

1) Review OMG Progress & PLA state of the art

2) Identify case/test studies

3) Formalise PLA Meta-model

4) Develop models

(Desired) US

contribution • Maturity in M&S tool

• Software Product Line Engineering Knowledge

(Desired) EU

contribution • Speciality in formal models

• Software expertise in models//tools exchange and interoperability

• Expertise in embedded systems & MBSE

Collaboration

instruments.

Enablers & barriers

to collaboration.

• Funding

• Workshops for vendors, users, & researchers to discuss project

Barrier: competition among tool vendors

Why should the

US/EU fund this

project (as opposed

to an alternative

funder)?

In the past years the development of MBSE tools are driven by US initiative. Progress is limited while skills of

EU researchers could potentially close current gaps in MBSE tool development.

This project has promise of success at the relevant level with US collaboration, but still offers EU incentive,

competitive advantage even if the US does not engage.

Baseline state of

the art (key existing

technologies)

OMG standards, all of the tool vendors and what they have

Vendors: US – IBM; NOMAGIC; PTC

EU: Modelio, SCADE

Related roadmap

elements

Developments in M&S (Gaps): 1; 3; 4; 7 Collaboration opportunities:

Collaboration Opportunity Ideas

1. Cloud-based modelling of real-time data

2. Big-data analytics modelling via machine learning

3. A platform could be established, such as this workshop, to understand the differences and commons to advance in CPSs, its tools and applications for having a better / suitable approaches

4. In EU, most of the researches aim public / society impact of the results. Therefore, we can learn from you. Especially in clean energy and public transportation. Since in US, transportation is the largest pie in energy

5. Sustainable energy sources are mostly deployed in EU; however there are concerns about the cost that affect society. Therefore, we can focus on to best applications in EU / secure & reliable ones / and compare with US

6. Identify tangible use cases with crisply defined objectives and not getting too complex in scope

7. Waste heat as a supplemental resource / W-t-e; part of the concept of net-zero buildings

Dream Project Big-data analytics modelling via machine

learning Team members:

Aim, objectives &

application domain

of the project

Explore ways to reduce energy usage using big data analysis and visualisation

Green buildings application domain

(Desired) US

contribution US energy data

Introduce PI System (OSIsoft) to EU

(Desired) EU

contribution Expertise in conservation and green buildings

Collaboration

instruments.

Enablers & barriers

to collaboration.

Joint workshop(s) on PI System , … (co-located or distributed)

1. Tutorial on what PI System is, everyone uses same data set. Use different tools to analyse / visualise the

data

2. Characterise energy usage on their own campus.

Why should the

US/EU fund this

project (as opposed

to an alternative

funder)?

Baseline state of

the art (key existing

technologies)

PI System

Analysis tools (e.g. Matlab)

Visualisation tools

Related roadmap

elements

Developments in M&S: Collaboration opportunities:

Outputs: Test Cases Theme 4 EU workshop, 16th June, 2016 – Kongsberg, Norway

Chaired by: Luminita Ciocoiu, Loughborough University

1) Transatlantic standardised guide for cross-cultural MBSE • Toyota Powertrain Benchmark ( 3 votes for DP1 and 2 votes for

DP2) • Civil engineering and SMART cities (3 votes for DP1) • New proposed Test Cases:

o Test Case for Autonomous Driving Vehicles

2) US and EU collaboration on MBSE tool PLA Standard

• Lane-change Scenario (4 votes for DP2) • Michigan M-City (3 votes for DP2 and 1 vote for DP1)

Test Cases associated with Dream Projects

Test Cases associated with Dream Project 1

Solution Selection Overview,

Purpose and

Structure of the

potential test

case

www. es. ucr.edu/~jinx Verification challenges for tools on hybrid sys. Includes various-complexity models with representative reqts + example tool perf. results. Different driver behaviour patterns. Different tools performance./interoperability of tools. Compatibility of tools/design Protection of sensitive information.

Organization/in

dividual

holding the test

case

Open source, see above. J. Xiaoqing et al. “Powertrain control verification benchmark”, HSCC 2014.

Procurement

protocol HTTP:CPS-VO.ORG/model/12108

Other

comments More benchmarks at: http://CPS-VO.ORG/GROUP/ARCH/BENCHMARKS

Potential Test

Case TOYOTA Powertrain Benchmark

Team

members:

Solution Selection

Overview, Purpose

and Structure of the

potential test case

Munich city is providing data, but may not be at the right level of fidelity.

Logistics fleet data (e.g. DHL) already exists. E.g. sensors on vehicles and in cab to

optimise.

Fidelity standard need be agreed

Automotive industry has good simulation tools for isolated vehicles (windchill tool –

virtual wind tunnel)

Agree on what tool to use

Gaming industry – game engines

Link to Collaboration

Opportunities/Dream

Projects

One above

Address Dream Project 1

Domain As above Civil engineering

Competency level:

Basic (now); Moderate

(3-5years); Advanced

(7-10years)

Whole time through – depending on the level of maturity.

Organization/individu

al holding the test

case

AVL (Austrian); Governments; Contractor.

PTC ; Automotive industry; regulatory body (SAE)

German projects (Bernard to provide details)

Procurement

protocol

Other comments

Potential Test

Case Civil engineering & SMART cities

Team

members:

Solution Selection Overview, Purpose

and Structure of the

potential test case

• Sensors (on-vehicle; infrastructure)

• Regulations (traffic; norms)

• Design and validate

• Fidelity

Link to Collaboration

Opportunities/Dream

Projects

1, 2

Domain Automotive (autonomous driving)

Competency level:

Basic (now); Moderate

(3-5years); Advanced

(7-10years)

Moderate (3-5 years)

Organization/individu

al holding the test

case

• 1 US company (Google?; Tesla?)

• Standardisation body

• 1 EU company (Volvo?)

• Governmental agencies

Procurement

protocol

Other comments

Potential Test

Case

Test Case for Autonomous Driving

Vehicles

Team

members:

Test Cases associated with Dream Project 2

Solution Selection Overview,

Purpose and

Structure of the

potential test

case

• Multi-x (disciplines, views)

• Human-machine interaction

• Uncertainty

- “Autonomy” (Functional Safety)

- Emergent behaviour

(unplanned Interplay)

(stochasticity)

• Collaboration

- Human-in-the-loop

- ITS Hierarchy

- Component-based

Organization/in

dividual

holding the test

case

• OFFIS on human behaviour in the loop

• Chalmers and VCC on Lane-change control. (to be checked)

• KTH (to be checked)

• Regulatory bodies

• Model/simulation developers

Procurement

protocol

NA

Other

comments

NA

Please include the two bullets from the Michigan M-City Potential Test Case

Potential Test

Case Lane-change Scenario

(scenario – “behaviour complexity”)

Team

members:

• Regulation details • Models & simulation

developed for the scenario

Solution Selection Overview,

Purpose and

Structure of the

potential test

case

A “mode” city where scenarios for autonomous vehicles can be

tested. – is there a model of the city?

Data gathered from these test scenarios can be used to validate

simulation approaches. For example:

- Human behaviour data to improve human behaviour models

- Sensor data (uncertainty, noise)

- Vehicle dynamics models

Organization/in

dividual

holding the test

case

U Mich, Ford, Google, Apple, etc. (Apple is doubtful)

Many companies may have this type of data.

Also London autonomous vehicle testing program.

Procurement

protocol - Collaboration between industry, academia, (possible government)

to standardise a model and data set and hopefully access to all.

Input/ Output

specification - A set of scenarios / test cases

Other

comments - Standardised model and data/ test cases should be necessary

for regulators to validate safety.

- Models and data/test cases suitable for testing tools and

languages against PLA meta-models

Potential Test

Case Michigan M-City

Team

members:

Solution Selection Overview, Purpose

and Structure of the

potential test case

Traffic Management SoS behaviours and Failures

- Existing MBSE models suitable for formal testing

- Sensor data

- Traffic management models

- SoS control architecture & strategies

Link to Collaboration

Opportunities/Dream

Projects

US & EU Collaboration on MBSE tools PLA standards

Domain Transportation

Competency level:

Basic (now); Moderate

(3-5years); Advanced

(7-10years)

Moderate (outputs and publications from COMPASS)

Organization/individu

al holding the test

case

COMPASS Deliverables: D24.2, D33.3, D43.3

www.compass_rsearch.eu/deliverables.html

Procurement

protocol

N/A for COMPASS

Some MBSE tools should be provided by vendor partners

Other comments

Potential Test

Case TM SoS Case Study

Team

members: