PhD Thesis Defense http://publications.polymtl.ca/1256/1/2013_MartinTapp.pdf

1. AUTOMATING SYSTEM-LEVEL
DATA-INTERCHANGE SOFTWARE
THROUGH A SYSTEM INTERFACE
DESCRIPTION LANGUAGE
PRESENTED BY MARTIN TAPP
DEPARTMENT OF COMPUTER ENGINEERING
DECEMBER 2, 2013
Ph.D. Thesis Defense

2. Full Mission Simulator Platforms
Context
2

Enable Better System: Integration | Interoperability
 Focus:
System Interfaces | Data Exchanges

3. Multi-Architecture Environment
Background
3

4. Problem Statement
System Integration | Interoperability Challenges
4

Data Compatibility
Units: Radians vs. Degrees
 Frame of Reference: Geodetic vs. Geocentric


Data Representation Compatibility
Structure: Protocol peculiarities (e.g. Objects vs. Messages)
 Duplicated Definitions: Copy in each architecture


5. Problem Statement (cont.)
System Integration | Interoperability Challenges
5

System Interface: Evolution | Governance

Change Introduction:
Complex Impact Prediction + Validation



What changed?
Change occurs in which architecture?
Link between each architecture representation?
Common Language:
Common Understanding between Stakeholders
 Unambiguously Capture:
System Interfaces | Data Exchanges


Machine-Processable System Interface Descriptions

6. Research Questions
6

Q1


Q2


What should be Formally Described in Order to Capture
System Interfaces and the Various Aspects Surrounding their
Data Exchanges, and How?
How should Multi-Architecture Considerations be Captured?
Q3

How should System Interface Descriptions be Used to
Automate Some of the Tasks Involved in
System Integration and Interoperability?

7. Proposal
7

System Interface Description Language (SIDL)

Addresses

Q1 (What + How)



What: Relevant language elements identified
How: Domain-Specific Language
Q2 (Multi-Architecture Considerations)

Architecture-Agnostic: From SIDL to specific architectures

8. Proposal (cont.)
8


Method to Automate the System-Level Data-Interchange
Software from System Interface Descriptions
Addresses

Q3 (Automate)

SIDL Model Compiler + Code Generation



Data Model
Data Serialization
Communication Interface

9. Why a Domain-Specific Language (DSL)?
Hiding Software Complexity
9


In the language of its stakeholders
Can treat model as source code [Llorente]

Scales better than UML [Eysholdt]

Simplifies Change Identification [Eysholdt]

Compiler enables: Strong Semantics + Validation + Code Generation [Wang]

10. System Interoperability Facets
Taxonomy Basis
10

11. SIDL Conceptual Model
Language Elements
11

12. Capturing System Interface Descriptions
Related Work
12
HLA
OMT
Interface

Data
Connection
WSDL
IDL
FACE



AADL



Transport








Multi-Architecture Considerations

Complex Validation Rules



Change Identification




WSDL: Similarity between Services and Systems
SIDL

13. Defining Systems Interfaces
Interface Facet
13

Port: input or output data

Data type specified with of
system RadarSensor:
input Entities of Entity
output RadarCrossSections of RcsList
...
RCS: Radar Cross Section
Entities port inputs
Entity messages

14. Defining Data Types
Data Facet
14

entity: structure with fields
entity Entity:
EntityIdentifier as EntityIdentifier
RcsSignatureIndex as short
...
Field’s representation
specified with as
Value types:
• integers, floating points
• chars, strings
• booleans
• enumerations

15. Abstract Level
Data Facet
15

Could define EntityIdentifier this way
entity EntityIdentifier:
Site as ushort
AppId as ushort
EntId as ushort

Context: Multi-Architecture | Heterogeneous Systems

How do we relate EntityIdentifier to other kinds of identity?


Data models contain many
What if identity is represented in other ways?


Different size (8bit, 64bit, 128bit)
Different structure (UUID, GUID, 4 integers)

16. Abstract Level (cont.)
Data Facet
16

Let’s raise the abstract level


info: something descriptive in nature
fact: concrete info representation
Specific identity
representation
info Name
info Description
info UniqueIdentity
Links all identity
representations
together
fact EntityIdentifier of UniqueIdentity
Site as ushort
AppId as ushort
EntId as ushort
fact OtherIdentity of UniqueIdentity
Id as uint

17. Abstract Level (cont.)
Data Facet
17

Going further


observable: something quantified through physical world measurement
measure: concrete observable representation with frame | unit
Specific angle
representation
observable Orientation
observable Angle
unit Radian
frame TrueNorth
Links all angle
representations
together
measure AngleRadian of Angle as single:
units Radian
frame TrueNorth
precision 0.000001

18. Abstract Level (cont.)
Data Facet
18

What if a system’s interface is not aligned
with a reference data model?

view: window over one or more entity

Specific
interest
Adapt
name
Enables System Interface Adaptation
view BeamAntennaDegrees:
select BeamAntennaStruct.AzimuthWidth as AngleDegree
select BeamAntennaStruct.ElevationWidth as AngleDegree
view AppAndWideEntityNumber:
select EntityIdentifier.AppId
select EntityIdentifier.EntId as uint:
alias EntityNumber
Adapt unit
Adapt data
representation

19. Connecting Systems Together
Connection Facet
19
bus RadarSystemBus:
...
channel Detections of DetectionList:
connect RadarProcessor.Detections
connect RadarDisplay.Detections
Channels connect
system ports
together

20. Specifying Protocol Details
Transport Facet
20

binding: captures bus protocol details

Captures architecture-specific considerations (Q2)
binding HlaBinding of RadarSystemBus as HLA.Protocol1516_2010:
channels:
encode DetectionList as HLA.objectClass
Common
channel
details
Specific
channel
details
Describe
encoding
qos:
Reliability = BestEffort
channel Detections:
qos DetectionList.Items:
Reliability = Reliable
Specify
protocol
Describe
quality of service
(QoS)
bus RadarSystemBus:
...
channel Detections of DetectionList:
connect RadarProcessor.Detections
connect RadarDisplay.Detections

21. Specifying How to Access a Bus
Transport Facet
21

network: provides bus access through endpoints
network RadarSystemNetwork of RadarSystemBus:
endpoint Hla of HlaBinding


binding describes how data is exchanged
network describes where to access it

22. Using SIDL Descriptions
22

System implementations refer to specific system | endpoint

Unambiguously Captures

System Interfaces | Data Exchanges



system: Covers Interface | Data
endpoint: Covers Transport | Connection
Can completely derive the data-interchange software

23. Data-Interchange Software Automation
23

Two-Stage Workflow
Modeling
 Code Generation


Why not One-Stage?

Prevents reusing SIDL descriptions directly

i.e. reuse library vs. share source code

24. Modeling Stage
Data-Interchange Software Automation
24
What
Know-How
How
SIDL
Description(s)
SIDL
Libraries
SIDL Model Compiler
SIDL Library
Element definitions
used in SIDL
libraries

25. Code Generation Stage
Data-Interchange Software Automation
25
What
System
+ Endpoint
+ Settings
SIDL
Libraries
Shared with
Modeling Stage
Target language
e.g. C++, C#
Know-How
SIDL Code Generator
How
System-Level
Data-Interchange
Software
Protocol support +
code gen.
simplification

26. Validation Strategy
26




Identify use cases with Subject Matter Experts (SMEs)
Implement test cases composed of test systems
Define language with SMEs
Prototype language implementation
Model test systems in SIDL
 Generate data-interchange software


Refactor test systems accordingly
Validate test cases
 Improve language from SME feedback
 Iterate again if

Use cases not achieved
 Data-interchange software requires manual intervention


27. Discussion
27

Introduced System Interoperability Facets

Prior: Levels of Conceptual Interoperability Model [Tolk]


Characterized attainable levels of interoperability between systems
Proposed New Taxonomy

Common language shared by stakeholders

28. Discussion (cont.)
28

Simplified Validation | Evolution | Governance


Dedicated language to describing system interfaces
Captured Multi-Architecture Considerations

Architecture-Agnostic Format

Specific details captured with binding | network | endpoint

29. Discussion (cont.)
29

Automated the System-Level Data-Interchange Software

Generated test cases entirely from SIDL descriptions


Architecture-agnostic code generator


System Interface, Data Model, Serialization, Architecture-Specific Artifacts
Multi-architecture considerations natively captured in SIDL
Enabled System Interface Reuse


Modeled system interface variability with views
Enable system reuse across multiple platforms in support of product
lines

30. Limitations
30

More than Semantic

SIDL covers up to Semantic Level of Conceptual Interop. Model [Tolk]


Conversion Modeling

view support limited to language side


Higher levels would enable further System Interoperability | Automation
Requires new language elements to cover conversions
Configuration in Support of Modeling

Information not captured by SIDL left as configuration data


E.g. communication middleware configuration

Derive new elements only when
What to capture in SIDL?


Standardized
Impact system interoperability in uniform way

31. Conclusion
31

Problem of formally describing system interfaces

Can be generalized to other domains


Operational systems: e.g. Aerospace, Automotive
Enabled Better System: Integration | Interoperability

32. Capturing Data Model Mappings
Future Work
32

Simplify Gateway Creation
 Provide
architecture-agnostic way of specifying
mappings (i.e. Interoperability logic)

33. Workflow-Driven Development
Future Work
33
-Hardware-Aware Software
-Legacy Assets Integration
Know-How
What
How
-Multi-Language Integration
-Debugging at the DSL Level

34. Questions?
34

Thank You!

35. References
35

Llorente


Eysholdt


Moritz Eysholdt and Johannes Rupprecht, "Migrating a large modeling
environment from XML/UML to Xtext/GMF," in Proceedings of the ACM
international conference companion on Object oriented programming
systems languages and applications companion, 2010, pp. 97-104.
Wang


César de la Torre Llorente, "Model-Driven SOA with Oslo," The
Architecture Journal, vol. 21, pp. 10-15, 2009.
Wenguang Wang, Andreas Tolk, and Weiping Wang, "The levels of
conceptual interoperability model: Applying systems engineering
principles to M&S," in Proceedings of the 2009 Spring Simulation
Multiconference, San Diego, 2009.
Tolk

Andreas Tolk, Charles Turnitsa, and Saikou Diallo, "Implied ontological
representation within the levels of conceptual interoperability model,"
Intelligent Decision Technologies, vol. 2, no. 1, pp. 3-19, February 2008.

36. References (cont.)
36

HLA OMT


WSDL


"Technical Standard for Future Airborne Capability Environment (FACE™), Edition 2.0," The Open
Group, C137, 2013. [Online]. https://www2.opengroup.org/ogsys/catalog/c137
DDS


"Architecture Analysis & Design Language (AADL)," SAE, AS5506, 2012. [Online].
http://standards.sae.org/as5506b
FACE


"Interface Definition Language (IDL) 3.5," Object Management Group, IDL35, 2013. [Online].
http://www.omg.org/spec/IDL35
AADL


"Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language," W3C, wsdl20,
2007. [Online]. http://www.w3.org/TR/wsdl20
IDL


"IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) Object Model
Template (OMT) Specification," IEEE, IEEE Std 1516.2-2010, 2010.
"Data Distribution Service for Real-time Systems Version 1.2," Object Management Group, formal/0701-01, 2007.
DIS

"IEEE Standard for Distributed Interactive Simulation-Application Protocols," IEEE, IEEE Std 1278.12012, 2012.

37. Simulation
Background
37
Aircraft
Behavior
Position
Velocity
Acceleration
Aircraft object
Interaction

38. Distributed Simulation
Background
38

39. Stakeholder Perspectives
System Integration | Interoperability Challenges
39

System Integrators

Heterogeneous System Interfaces


Multiple Suppliers
System Suppliers

Heterogeneous Platforms

Reuse System Across Multiple Platforms
(i.e. Enable Product Line Support)

40. System Interoperability Facets
Taxonomy Basis
40
Interface
Transport | Data
Connection

41. SIDL Data Model
41

42. Radar System Example
42

Let’s express this in SIDL
(RCS = Radar Cross Section)

43. Modeling Stage Implementation
43
What
SIDL Description
(SharpDevelop Editor)
Know-How
SIDL Description Compiler
(Boo)
How
SIDL Library
(.NET)

44. Code Generation Stage Implementation
44
What
System
+ Endpoint
+ Settings
SIDL Libraries
(.NET)
Know-How
SIDL Code Generator
(C#)
How
System Interface
(C++, C#)

45. Test Cases
Experimental Results
45

Colliding Balls


Ownership Transfer


Representative distributed system
Typical distributed sim. function
Gateway

Multi-architecture test case

46. Automating System-Level Data-Interchange Software
Experimental Results
46

Fully generated data-interchange software from SIDL

System Interface | Data Model | Data Serialization


Architecture-Specific Artifacts


C++ | C#
Data Model Representations: HLA OMT | DDS IDL
Protocol

HLA | DDS | DIS

47. SIDL Modeling – SME Feedback
Experimental Results
47

Minus

Better code + SIDL integration: two development environments


No code completion + better syntax highlighting


Integrate SIDL in code development environment
Support present except not implemented
Array syntax


Some did not like it
Lacks lower bounds

48. SIDL Modeling – SME Feedback (cont.)
Experimental Results
48

Plus

SIDL as source code



Easier understanding of model evolution
Same revision control system and comparison tool
Meaningful validation errors | Strong semantics


Code Generation


Breaking changes easily pinpointed (both for Modeling + Code Generation)
Increased efficiency as focus not on data-interchange software
Multi-architecture peculiarities dealt in uniform way

System experts could delegate network and binding to integrators