atoolintegraonapproachforarchitectural … · 2019. 12. 1. ·...

Industrial Cyber-Physical Systems

Sponsored by the iCyPhy Research Consor4um, a collabora4on of UC Berkeley, Caltech, IBM, and United Technologies.

A Tool Integra-on Approach for Architectural Explora-on of Aircra6 Electric Power Systems

Hokeun Kim, Liangpeng Guo, Edward A. Lee and Alberto Sangiovanni-‐Vincentelli

The 1st IEEE Interna-onal Conference on Cyber-‐Physical Systems, Networks, and Applica-ons

Taipei, Taiwan August 19 -‐ 20, 2013

EECS, University of California, Berkeley

Introduc-on

•  Aircra6 electric power system (EPS) – Genera-on, conversion and distribu-on of power for aircra6 u-li-es

–  Safety-‐cri-cal cyber-‐physical system –  Consists of power generators, buses, contactors, loads and sensors

–  Becoming increasingly more complex •  References

–  K. Emadi and M. Ehsani, “Aircra6 power systems: technology, state of the art, and future trends,” Aerospace and Electronic Systems Magazine, IEEE, vol. 15, no. 1, pp. 28–32, 2000.

–  L. Guo, M. Maasoumy, M. Mozumdar, P. Nuzzo, N. Ozay, U. Topcu, H. Xu, R. Murray and A.Sangiovanni-‐Vincentelli, "Aircra6 Electric Power System: Descrip-on, Specifica-ons and Design Challenges", MuSyC DSCS internal report, March 2012, unpublished

CPSNA 2013 2

Introduc-on (cont’d)

•  Characteris-cs of modern safety-‐cri-cal cyber-‐physical systems – Consist of heterogeneous components – Complex systems both in func-onali-es and underlying architectures

– Timing behavior is part of correctness – Valida-on of reliability is cri-cal

CPSNA 2013 3


•  Design challenges – How can we model heterogeneous components in safety-‐cri-cal cyber-‐physical systems together?

– How can we cope with architectural explora-on problem with complex func-onali-es?

– How can we validate -ming behavior in advance?

CPSNA 2013 4


•  Tool integra-on approach –  Crea-ng a plaborm for architectural explora-on of safety-‐cri-cal cyber-‐physical systems by integra-ng Ptolemy II and Metro II

•  Ptolemy II – A system design framework suppor-ng experimenta-on with mul-ple heterogeneous models of computa-on (e.g. DE, SDF, SR, etc.)

•  Metro II – Design environment for plaborm based design where the mapping can be easily changed and thus suitable for architectural explora-on

CPSNA 2013 5


•  Design challenges revisited –  How can we model heterogeneous components in safety-‐cri-cal cyber physical systems together?

•  By using Ptolemy II that supports mul-ple models of computa-on

–  How can we cope with architectural explora-on problem with complex func-onali-es?

•  By decoupling func-onal aspects from architectural aspects using Metro II

–  How can we validate -ming behavior in advance? •  By running co-‐simula-on on the integrated plaborm of Ptolemy II and Metro II

CPSNA 2013 6

Approach

•  Approach overview

CPSNA 2013 7

Architectural Model

Task1 Task2 Task3

Scheduler Interac4on

Ptolemy II Metro II

SystemC ( + Metro II Extension)

6/12/13 3:27 PMForCapture2

Page 1 of 1file:///Users/hokeunkim/Documents/MATLAB/ForCapture2_slwebview_files/slwebview.svg

RHVLHV

a b c

a b c

a b c

a b c

B6B5

B4B3 B2B1

EXTAPU

Right AC LoadLeft AC Load

? ForCapture2

•  Aircra6 EPS specifica-on

Func-onal Model

CPSNA 2013 8

Generators •  Generate AC power •  May have faulty behaviors •  Main & backup generators

AC Loads •  Always need to be powered

by exactly one generator •  Can be powered off while

generators are replaced

Contactors •  Transfer power from

generators to loads •  Set up control paths

Courtesy : P. Nuzzo

Func-onal Model (cont’d)

•  A supervisory controller for aircra6 EPS (Ptolemy II)

CPSNA 2013 9

Director •  Implements Synchronous / Reactive •  Metro II extension

Input •  Health status of Generators

Output •  Control signals for Contactors

Sub tasks

•  Tasks inside of the supervisory controller

6/12/13 3:27 PMForCapture2

Page 1 of 1file:///Users/hokeunkim/Documents/MATLAB/ForCapture2_slwebview_files/slwebview.svg

RHVLHV

a b c

a b c

a b c

a b c

B6B5

B4B3 B2B1

EXTAPU

Right AC LoadLeft AC Load

? ForCapture2

Func-onal Model (cont’d)

CPSNA 2013 10

ArrangeLeftPath (ALP) •  Selects a generator for

Left AC Load •  Based on health status

ArrangeRightPath (ARP) •  Selects a generator for

Right AC Load

ControlSignalGen (CSG) •  Generate control signals for contactors (B1 ~ B6) •  Based on the generator selections of ALP and ARP

Architectural Model

CPSNA 2013 11

•  Architectural model overview & interac-on with the func-onal model

Named Pipes

Task1 Task2 Task3

Wait for SystemC events

Notify systemC events

Propose or notify Metro II events

SystemC Architectural Model

Ptolemy II Functional Model

Scheduler

1 Introduction

This document details the ongoing meetings among the authors to discuss the Metro II executionsemantics of mapping. The outcome of these meetings, held primarily in the Summer of 2007, is a setof three proposals for the execution semantics of mapping in Metro II. The purpose of this documentis to clearly illustrate the pros and cons of these three proposals as well as provide concrete designscenarios by which these and future proposals will be judged. In order to illustrate the semantics, handexample traces are provided for each proposal. These hand examples are created at a level of granularitywhich provides enough insight to compare the proposals without overwhelming the reader.

More importantly however, the design scenarios will serve as “necessary, but not su!cient” bench-marks for any modifications or other proposed execution semantics. The design scenarios are intendedto capture a wide variety of potential situations a designer may want to model. We propose that thetables which contain the hand traces in this document set the standard by which Metro II execution ispresented.

This document describes four main pieces: the general execution semantics shared by all proposals,the execution semantics’ assumptions, the individual design scenarios, and each proposal with its ac-companying hand execution traces for the design scenarios. It is the authors’ hope that this documentwill prevent ambiguity regarding the semantics and facilitate discussions on Metro II. This is achievedby clearly defined scenarios and a standardized way to present Metro II execution.

It should be noted as well that this document is not intended to be a comprehensive discussion ofMetro II. We refer the reader to [2] for more information (which should be read before this document).Aspects of this document may later be used for a future journal submission (i.e. an IEEE Transactionson Computers special issue). Also the reader should inspect the MetroII code base, as this documentmay not reflect the latest implementation details.

2 Execution Semantics Overview

1. BaseModel

2. QuantityAnnotation

3. Constraint

Solving

Proposed Events

Proposed Eventswith Annotations

EnabledEvents

Figure 1: Metro II: Three Phase Execution

This section describes the common portion of the execution semantics for all of the proposals. Figure1 illustrates the current 3-phase execution semantics consisting of:

1. Base phase - Where components execute concurrently and propose events.

2. Quantity annotation phase - Where proposed events are assigned physical quantities such astime or power.

3

Architectural Model (cont’d)

•  Metro II execu-on seman-cs & Co-‐simula-on flow

CPSNA 2013 12

Named Pipes

Task1 Task2 Task3






Scheduler

1 Introduction






1. BaseModel


3. Constraint

Solving

Proposed Events


EnabledEvents





3


CPSNA 2013 13

Named Pipes

Task1 Task2 Task3






Scheduler


e1

e1, e2, e3 – Metro II events

e2 e3

1 Introduction






1. BaseModel


3. Constraint

Solving

Proposed Events


EnabledEvents





3


CPSNA 2013 14

Named Pipes

Task1 Task2 Task3






Scheduler


e1, e2, e3 – Metro II events t1, t2, t3 – Global clock (e1,t1) (e2,t2) (e3,t3)

1 Introduction






1. BaseModel


3. Constraint

Solving

Proposed Events


EnabledEvents





3


CPSNA 2013 15

Named Pipes

Task1 Task2 Task3






Scheduler


e1, e2, e3 – Metro II events t1, t2, t3 – Global clock Global clock += (scheduling overhead +execution time of tasks +synch overhead + etc.)

[Task1,(e1,t1)], [Task2,(e2,t2)], [Task3,(e3,t3)]

1 Introduction






1. BaseModel


3. Constraint

Solving

Proposed Events


EnabledEvents





3


CPSNA 2013 16

Named Pipes

Task1 Task2 Task3






Scheduler


e4

e4, e5, e6 – Metro II events

e5 e5


•  Architectural parameters – Scheduling overhead – Priority of tasks – Speed of processing elements (or execu-on -mes of tasks)

– Paralleliza-on of independent tasks – Synchroniza-on overhead for parallelized tasks

CPSNA 2013 17

Experiments and results

•  Example architectural alterna-ves

CPSNA 2013 18

Candidate #

Scheduling Overhead (ns)

Execu4on Time (ns) ALP/ARP/CSG

Paralleliza4on of ALP & ARP

Synch Overhead (ns)

1 10 40/45/20 No -‐

2 10 65/70/40 Yes 5

3 10 50/55/30 Yes 15

Candidate # Total Execu4on Time (ns)

1 1150

2 1250

3 1100

•  Results –  Ten itera-ons of func-onal model with a given test bench

Shortest (=Fastest)

No Parallelism

Parallel Processing

Slower Than #3

Less Overhead Than #3

Least Total Execution Time

Experiments and results (cont’d)

•  Measuring co-‐simula-on overhead – Total simula-on -me of Ptolemy II model

•  Co-‐simula-on VS Standalone (Ptolemy II only)

CPSNA 2013 19

2,479

4,944

7,547

10,168

12,683

1,625

3,297 4,675

6,246 7,687

2000 4000 6000 8000 10000

Tota

l exe

cutio

n tim

e (m

s)

Number of iterations of the SR director

Measurement of co-simulation overhead Co-simulation

Standalone

•  Linear overhead •  1.58x execution time Potential for Scalability

Conclusion

•  Summary – Co-‐simula-on environment suppor-ng performance predic-on and comparison of architectural candidates for safety-‐cri-cal cyber physical systems

– Through a tool integra-on approach with •  Ptolemy II – Supports heterogeneous MoCs •  Metro II – Decouples the modeling of func-onal aspects and architectural aspects

CPSNA 2013 20

Conclusion (cont’d)

•  Future work – Func-onal model

•  More complex safety-‐cri-cal system examples •  Examples with heterogeneous directors (MoCs)

– Architectural model •  Crea-ng general architectural models •  Considering more architectural parameters (e.g. memory access overhead, I/O opera-on overhead)

CPSNA 2013 21

Q & A

CPSNA 2013 22

Thank you!