AToolIntegraonApproachforArchitectural … · 2019. 12. 1. · Architectural"Model"(cont’d)"...
Transcript of AToolIntegraonApproachforArchitectural … · 2019. 12. 1. · Architectural"Model"(cont’d)"...
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
Introduc-on (cont’d)
• 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
Introduc-on (cont’d)
• 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
Introduc-on (cont’d)
• 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
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)
CPSNA 2013 13
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
• Metro II execu-on seman-cs & Co-‐simula-on flow
e1
e1, e2, e3 – Metro II events
e2 e3
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)
CPSNA 2013 14
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
• Metro II execu-on seman-cs & Co-‐simula-on flow
e1, e2, e3 – Metro II events t1, t2, t3 – Global clock (e1,t1) (e2,t2) (e3,t3)
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)
CPSNA 2013 15
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
• Metro II execu-on seman-cs & Co-‐simula-on flow
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
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)
CPSNA 2013 16
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
• Metro II execu-on seman-cs & Co-‐simula-on flow
e4
e4, e5, e6 – Metro II events
e5 e5
Architectural Model (cont’d)
• 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!