Unmanned Systems Ux S Control Segment UCS Architecture

  • Slides: 62
Download presentation
Unmanned Systems (Ux. S) Control Segment (UCS) Architecture Model AS 6518 A – pre-release

Unmanned Systems (Ux. S) Control Segment (UCS) Architecture Model AS 6518 A – pre-release Tutorial 01 Jim Albers Secretary, SAE AS-4 UCS Architecture Chair AS-4 UCS-1 UCS Architecture User Group Fastpilot, Inc. jalbers@fastpilot. com Except where otherwise noted, you may use and redistribute this content as you wish according to the Creative Commons Attribution 4. 0 International license. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Purpose of this introduction. • Introduce the UCS Architecture at a high level to

Purpose of this introduction. • Introduce the UCS Architecture at a high level to understand the basic organization of the constituent models: • Conceptual vs. Logical levels • Service, Message, and Domain Data models. • Begin hands-on work with the UCS Architecture Model in Sparx Enterprise Architect EA. • Show to navigate the model in EA using EA tools and UCS add-on scripts. • Introduce basic scripting and model query tools. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Introduction Outline Open Architecture and UCS Downloading UCS Architecture Release A (AS 6518

UCS Introduction Outline Open Architecture and UCS Downloading UCS Architecture Release A (AS 6518 A) UCS Service Oriented Architecture (SOA) UCS Conceptual and Logical Model (PIM) Walkthrough of the UCS Conceptual and Logical Model • Service Model • Message Model • Data Model • Primitive. Types and Constrained Primitive. Types • AS 6969 Quantities and UCS realizations. • UCS Product examples: • UCS Component – Vehicle. Flight. Status service provider • UCS Component – Vehicle. Flight. Status service consumer • Backup material • • • Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Download UCS Architecture Pre-Release AS 6518 A snapshots • Pre-release materials are only available

Download UCS Architecture Pre-Release AS 6518 A snapshots • Pre-release materials are only available to SAE AS-4 UCS Technical Committee members. • Contact Dorothy Lloyd (Dorothy. Lloyd@sae. org) for information on how to join the committee. https: //www. sae. org/servlets/works/committee. Home. do? comt. ID=TEAAS 4 UCS • In the AS 4 UCS Committee Work Area, navigate to ‘UCS Architecture’. • Each of the snapshot items contains a. zip file with the state of the model as of the indicated subversion revision number (e. g. r 1873) • Unzip the downloaded. zip file to get an EA. eap file to open in Enterprise Architect. 30 day trial, or free Enterprise Architect Reader: http: //www. sparxsystems. com/products/ea/downloads. html Fastpilot, Inc 2018, some rights reserved. UCS Introduction

The UCS Architecture Has Multiple Parts The whole of the UCS Architecture is referenced

The UCS Architecture Has Multiple Parts The whole of the UCS Architecture is referenced using the part number of the UCS Architecture Description – AS 6512 A The UCS Architecture document tree shows the relationships of the standards in the architecture. AS 6518 A MODEL is the set of architectural models delivered as an Enterprise Architect project file. The AS 6969 Data Dictionary for Quantities used in Cyber Physical Systems is not part of the UCS Architecture, but is foundational for it. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

AS 6512 A Document Tree Architecture Description AS 6512 A Version Description Document AIR

AS 6512 A Document Tree Architecture Description AS 6512 A Version Description Document AIR 6520 A Architecture Technical Governance AS 6522 A Model AS 6518 A UCS Architectural Model Package System Use Case Model Use Case Trace (UCTRACE) Package AIR 6519 A Domain Participant Model Package Service Contract and NFP Model Package Information Model Package Conformance Specification AS 6513 A References: AS 6969 Data Dictionary of Quantities used in Cyber Physical Systems Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Defining a SOA Service • SOA Services are defined per the “OASIS Service Description”

Defining a SOA Service • SOA Services are defined per the “OASIS Service Description” • Service Oriented Architecture – as used by the UCS Architecture is defined in the OASIS SOA Reference Model and SOA Reference Architectures. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Service Oriented Architecture (SOA) • As a Service Oriented Architecture (SOA), defines services

UCS Service Oriented Architecture (SOA) • As a Service Oriented Architecture (SOA), defines services as points of conformance, where services: • are capabilities provided or required by a UCS product • that can produce real-world effects, and • are accessed via service interfaces through which messages are exchanged according to an information model and message exchange protocol • The UCS SOA consists of: • Service Model: specifies Service. Interfaces that indentify a set of Interfaces required by Participants, defining how messages are exchanged. • Message Model: specifies Messages exchanged across interfaces between providers and consumers of a service. • Domain Data Model that specifies the content and logical structure of data elements exchanged by value or referenced by messages. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS SOA: Service + Message + Domain Data • Services are provided and used

UCS SOA: Service + Message + Domain Data • Services are provided and used via information exchanges (messages) that convey information, commands, requests, status about the operational world of interest. • In UCS the operational world of interest is defined as a Domain Data Model of entities, their relationships, and their properties (or attributes). • The Domain Data Model provides a key benefit vs. message-only models. • A message set by itself provides fragments of an overall picture. • The UCS Domain Data Model provides the complete unified picture that messages are conveying information about. • Every message in the UCS SOA is defined specifically in terms of the Domain Data Model. • Therefore we know that every message data element that references the same entities or relationships or properties in the domain data model means the same thing. • New messages, or other legacy message sets that are mapped to the Domain Data Model have clear meaning with respect to a common operational view. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Messages are defined by Domain Data Domain model for Mission. Tasks and Vehicles Message

Messages are defined by Domain Data Domain model for Mission. Tasks and Vehicles Message Mapping via “Projection” We will be looking at this in greater detail. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

The UCS SOA: • Avoids constraints on component architecture. Design, adapt, or reuse the

The UCS SOA: • Avoids constraints on component architecture. Design, adapt, or reuse the right component architecture based on non-functional requirements. • Complements component and deployment architectures like those specified by AS-4 JAUS or OMS. • Allows integration of legacy systems and new systems based strictly on exposing or using capabilities (services) via well-defined service interfaces. • Conforms to established OASIS Reference Model via a subset of the OMG SOA Modeling Language (Soa. ML) profile for UML. • See AS 6522 A for details on UCS use of Soa. ML concepts and metamodel. • See Appendix A in the OMG Soa. ML specification for detailed mapping of Soa. ML v 1. 0. 1 to the OASIS Reference Model. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Conceptual and Logical Models • The Conceptual Model has high level data abstractions

UCS Conceptual and Logical Models • The Conceptual Model has high level data abstractions for “Quantities” like Time and Mass, and service and message models that reference these high-level abstractions. There is insufficient information in the Conceptual definition of Time to produce a data item representing Time. • The Conceptual Model is based on AS 6969 Data Dictionary of Quantities used in Cyber Physical Systems, this provides the foundation for defining quantities that are usable in real systems. • The Logical Model is the Platform Independent Model (PIM) that ‘realizes’ the abstract quantities to a level at which conformant interfaces can be designed and implemented. For example, logical realization involves setting data units and precision. • The Conceptual Model is transformed into the Logical Model to produce the UCS Interface Control Document (ICD) in its text and ICD logical model forms. • UCS Architecture Conformance is assessed at the Logical Level. • Conformance claims may reference the traditional text / tabular ICD document or the ICD Logical Models (EA, Rhapsody, RSA, Cameo/Magic. Draw). Fastpilot, Inc 2018, some rights reserved. UCS Introduction

The UCS Model: Breaking it down. • Services Model (a. k. a. Domain Participant

The UCS Model: Breaking it down. • Services Model (a. k. a. Domain Participant Model) • Participants – roles relevant to service: client, server, mediator, proxy, etc. • Interfaces - interfaces by which Participants interact • Service. Interfaces – set of interfaces required to employ a service plus protocol • Message Model – definition of messages exchanged over Service. Interfaces • Domain Data Model – a description of the operational world: entities, their relationships, and their attributes. Define data referenced in Interface messages Service Message Domain Data Conceptual X X X Logical X X X Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Conceptual and Logical Model Relationships a. k. a. ‘Domain Participant Model UCS Conceptual

UCS Conceptual and Logical Model Relationships a. k. a. ‘Domain Participant Model UCS Conceptual Service Model Projection UCS Conceptual Domain Data Model UCS Conceptual Message Model Type. Ref Transform Refine Projection UCS Logical Service Model Conceptual Properties UCS Logical Message Model Type. Ref UCS Logical Domain Data Model Realize Logical Value Types Generated via transforms • The Logical Model is produced from the Conceptual Model by substituting ‘logical types’ for the conceptual property types. • The Logical Model is equivalent to the Conceptual Model in all respects except for the substitution of logical value types for conceptual property types. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Conceptual / Logical relationships. The wiring. Type. Ref Pro ject ion Transform Refine Realize

Conceptual / Logical relationships. The wiring. Type. Ref Pro ject ion Transform Refine Realize Transform Type. Ref Generated via transforms Fastpilot, Inc 2018, some rights reserved. UCS Introduction Tran

Implementers: Use the Logical Models. Use the Logical Service, Message, and Domain Data models

Implementers: Use the Logical Models. Use the Logical Service, Message, and Domain Data models to design and build UCS Architecture conformant products. • Work with AS 6518 A Conceptual Models if you are working on the next release of the UCS Architecture, or using the UCS Architecture for some non-UCS purpose. • The AS 6518 A Conceptual Models are the factory: with complex assembly jigs, scaffolding, wiring, and production processes. • The AS 6518 A Logical Model is generated from the Conceptual Model by substituting complete definitions for conceptual quantity types. In AS 6518 A, the Logical Model is the basis for UCS Conformance, details to be documented in AS 6522 A Technical Governance and AS 6513 Conformance. (NOTE: Alternate terminology will say that the basis for conformance is the ‘type substituted conceptual model’, but this is exactly the UCS Logical Model. ) Fastpilot, Inc 2018, some rights reserved. UCS Introduction

AS 6518 A Model Organization • Conceptual Model • Service Model • Message Model

AS 6518 A Model Organization • Conceptual Model • Service Model • Message Model • Domain Data Model • Logical Model • Service Model • Message Model • Domain Data Model • Extensions to AS 6518 A The multi-domain (ground and maritime) extensions are integrated into the core models. There is a set of experimental services, however, managed as a separate extension. Fastpilot, Inc 2018, some rights reserved. (The Conceptual Service Model-- the SOA model--is called “Domain Participant Model” for historical reasons, emphasizing the agents (SOA participants) that interact in the domain. ) UCS Introduction

AS 6518 A Extensions Mirror Model Structure Extension elements reference read-only Core elements via:

AS 6518 A Extensions Mirror Model Structure Extension elements reference read-only Core elements via: • Generalization/Specialization • Refinement • Dependency • Diagram Views Extension packages are integrated into the EA project, but managed in separate VC repositories. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Detailed examination of the submodels. • Service Model - SOA Service Models using Soa.

Detailed examination of the submodels. • Service Model - SOA Service Models using Soa. ML, describe the functional / behavioral aspects of the system, captured in Services that describe the capabilities that entities (or their proxies, mediators, controllers) provide and require. • Message Model – structure of SOA Message. Type elements and mapping to the Domain Data Model • Domain Data Model – model of data describing the operational world of interest: entities that interact in that world, their relationships and their properties. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Service Model Overview • For historical reasons the Conceptual Service Model is labeled

UCS Service Model Overview • For historical reasons the Conceptual Service Model is labeled “Domain Participant Model” • Defines UCS SOA Service. Interfaces and (some of) the roles participants must play as clients, servers, proxies, mediators, etc. • All bidirectional interaction requires two service interfaces. One, the client side, is the ‘conjugate’ and is noted with a tilde ‘~’ prefix. • All interactions are via asynchronous messages. This allows support for many kinds of message exchange patterns (MEPs). Call/Return, Request/Response*, Command/Status*, Publish/Subscribe, etc. • Therefore, interpret all UCS service interface operations as ’receptions' for asynchronous messages. (Early UCS modeling used UML synchronous operations, and that stuck. ) • UCS uses the OMG SOA Modeling Language (Soa. ML), which realizes the OASIS SOA Reference Architecture. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Service Model: Vehicle Flight Control • • EA Does not recognize is. Conjugate

UCS Service Model: Vehicle Flight Control • • EA Does not recognize is. Conjugate property on ports, so must explicitly define the ~Vehicle. Flight. Control Service. Interface. EA Will not automatically expose Service. Interface Provided and Required interfaces so must add by hand (and check). Model walkthrough: navigating across models. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Service Model: Participant Interactions All elements in this diagram link to the core

UCS Service Model: Participant Interactions All elements in this diagram link to the core model. Nothing is ‘drawn’. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Service Model: Protocol Example • In UCS AS 6518 A protocols are specified

UCS Service Model: Protocol Example • In UCS AS 6518 A protocols are specified using UML Activity diagrams. • This example shows that Vehicle. Flight. Control service supports familiar ‘call semantics’ using a pair of request/response interfaces. • A session. ID attribute is available for all messages to support stateful protocols. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Service Model: Migrating to Protocol Statemachines per JAUS • In UCS AS 6518

UCS Service Model: Migrating to Protocol Statemachines per JAUS • In UCS AS 6518 A protocols are specified using UML Activity diagrams, that are not syntactically correct with respect to UML 2. Cannot generate protocol code or do formal analysis. • The plan is to make all Service protocols formally defined using Protocol State Machines, possibly in Revision B. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

JAUS Access Control Protocol This is an example of a real-world control protocol. In

JAUS Access Control Protocol This is an example of a real-world control protocol. In your Tutorial 01 folder, open the model JAUS_Access. Control. eap Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Message Model: Overview • Each UCS Service ‘operation’ is an event reception for

UCS Message Model: Overview • Each UCS Service ‘operation’ is an event reception for a UCS Message. Type element. • UCS Messages have explicit derivations from the domain data model, given by Projection and refinement in the AS 6518 A, and captured in the Message Model ‘projection’ constraints. • UCS Messages are NOT persistent, they exist only for the duration of a data exchange. • UCS Messages can not be referenced by any other messages or data. • Persistent ‘messages’ are really domain entities like Commands, Requests, Statuses and must be represented by persistent domain data elements so they can be queued, referenced, etc. • Note the abstract type UCSPersistent. View and its specializations in the Data Model. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Message Model: Projections • Projections define message content and meaning (semantics) by mapping

UCS Message Model: Projections • Projections define message content and meaning (semantics) by mapping message data to the Domain Data Model. • Projections in the Conceptual Model are handled differently than in the Logical Model • Conceptual Model • One Projection connector per message attribute. • Projections do not have UML 2 Association semantics (e. g. does not specify a runtime reference between a message instance and an entity instance. • Logical Model • One Projection connector per entity referenced by a message. • Projection specification is given in the Object Constraint Language (OCL) • Logical projections produce executable code. • Logical projections are automatically generated during the transform process. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Conceptual Message Model UCS Message Model Conceptual Model Projections are a kind of “lines

Conceptual Message Model UCS Message Model Conceptual Model Projections are a kind of “lines and labels” query language. • The “line”, the Projection connector, sets the scope of the query. • The “label” says what attribute in the message (source rolename) has its value set to which entity attribute given by the target rolename. • Scheme limited in handling multiplicity (e. g. two Actions), data conversions, etc. Not UML 2 Association semantics. Conceptual Domain Data Model Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Message Model Logical Domain Data Model Fastpilot, Inc 2018, some rights reserved. Model

UCS Message Model Logical Domain Data Model Fastpilot, Inc 2018, some rights reserved. Model walkthrough: navigating across models, viewing constraints UCS Introduction

UCS Message Model: Logical Projections • A UCS Logical Projection Association specifies a one-way

UCS Message Model: Logical Projections • A UCS Logical Projection Association specifies a one-way link (via an entity reference) from a message instance to a referenceable entity instance. • An implementation of a message will have some platform specific identifier (GUID, tail number, etc. ) in the message implementing the entity reference and indicating which entity or entities the message is about. • The default name of the reference attribute is created by lowercasing the first name of the type and prefixing with an underscore: _vehicle. Navigation. Action • In future, can have multiple projections, say in an Intercept message, for interceptor and interceptee, with unique names or collections. • Can have links with multiplicity, like ‘escorted[1]’ and ‘escorters[0. . *]’ • The data specification for a projection is given in an OCL statement. derive: (self. air. Vehicle. Flap. Angle = self. _vehicle. Navigation. Action. air. Vehicle. Flap. Angle) and (self. landing. Gear. Status = self. _vehicle. Navigation. Action. landing. Gear. Position. Status. set. Point) and (self. air. Vehicle. Speed. Brake. Angle = self. _vehicle. Navigation. Action. air. Vehicle. Speed. Brake. Angle. angle) Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Domain Data Model UCS Message Model: Logical Projections • No need for source

UCS Domain Data Model UCS Message Model: Logical Projections • No need for source rolename. The domain entities never reference message instances that may be conveying information about them. • Target rolename gives a reference to an entity that the message is talking about. • The Object Contraint Language (OCL) is a formal language for making assertions about or querying UML 2 models. • OCL Projection constraints are simple statements about how message attribute values are derived. • In advanced usage, the OCL statements can reference data conversion operations, assertions about entity state, etc. • In future revisions, plan is to use OCL based Projection specifications exclusively. • More details in BACKUP section below. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Domain Data Model Overview • Primitive. Types • Platform-independent Real, Integer, String, Boolean.

UCS Domain Data Model Overview • Primitive. Types • Platform-independent Real, Integer, String, Boolean. (UML Primitive. Types plus Real) • UCS Constrained. Types • • • Primitive. Types with metadata: precision, units, etc. (extended UML Primitive. Type) Stereotyped by base Primitive. Type <<Real>>, <<String>>, etc. Designed to support XSD schema element attributes. • UCS Conceptual Quantity Types • • Quantities defined for Cyber Physical Systems (AS 6969) Linked by UUID to specifications in AS 6969. • UCS Logical Value Data. Types • • • Primitive, Enumeration, or Composite types that don’t have identity (UML Data. Type) Have attributes, but no navigable Association ends. (you cannot reference an instance of a datatype since it has no identity). Necessary to realize fundamental Conceptual Quantity types. • Entities • • Composite types with identity (UML Class) Have Attributes and Associations. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Domain Data Model UCS Constrained. Types Tagged values designed for convenient mapping to

UCS Domain Data Model UCS Constrained. Types Tagged values designed for convenient mapping to XSD element attributes. But use is Platform Independent. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Domain Data Model UCS Conceptual Quantity Types • Conceptual Quantity Types were called

UCS Domain Data Model UCS Conceptual Quantity Types • Conceptual Quantity Types were called “Observables” in previous versions of AS 6518. • Quantity types in AS 6518 A are based on the International System of Quantities ISO-80000, with elaboration of semantics in AS 6969 Data Dictionary for Quantities used in Cyber Physical Systems. • Quantities have complete semantics independent of any particular choice of measurement units and precision. • To produce executable software systems, choices about units and precision need to be made somewhere. In UCS, those choices are made at the logical level. For example: A Real number given in meters, with precision of 0. 001 meter, and range [-1000. 0, 70000. 0]. • Choices about bit encoding are made at the ‘platform level. ’ For example the realized quantity given above could be encoded as a string, an IEEE singleprecision, or a scaled integer. Encodings have well-defined, lossless conversions. • Any given Conceptual Quantity may have one or more Logical Realizations that mean the same thing as the quantity, and can, to some extent, be converted among. Fastpilot, the different realization types. Inc 2018, some rights reserved. UCS Introduction

UCS Domain Data Model UCS Logical Value Types realize Conceptual Property Types UCS Conceptual

UCS Domain Data Model UCS Logical Value Types realize Conceptual Property Types UCS Conceptual Property (Quantity) Types are data types used to store the observed state of a conceptual Quantity property. Per AS 6969, there are: • Nominal Properties: properties whose values do not have magnitude. • Aircraft tail number • Person social security number • Network endpoint address • Quantities: properties whose values have magnitude. • Mass • Pressure • Position • Speed and Acceleration UCS Logical Value Types are data types used to specify the value of the observed state of a conceptual property. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Domain Data Model Conceptual Quantities and Logical Value Types Conceptual Domain Data Model

UCS Domain Data Model Conceptual Quantities and Logical Value Types Conceptual Domain Data Model Logical Domain Data Model The WGS 84 Ellipsoid. Position logical value type realizes the conceptual Position. Vector quantity with a UML Realization relationship. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Domain Data Model Conceptual Quantities and Logical Value Types All AS 6969 Quantity

UCS Domain Data Model Conceptual Quantities and Logical Value Types All AS 6969 Quantity specifications are referenced via the AS 6969 UUID. These are UML Instances (“Instance. Specifications”), constant values. Model walkthrough: navigating tagged value refs. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Domain Data Model UCS UML Profiles – stereotypes and tagged values. AS 6518

UCS Domain Data Model UCS UML Profiles – stereotypes and tagged values. AS 6518 A will use three UML profiles: • UCS_DM_A – UCS Data Model profile, revision A • UCS_Soa. ML – UCS standard subset of Soa. ML 1. 1 with the addition of a version tag for Service. Interface elements. • UCS_NFP – Very simple profile for working with nonfunctional property requirements. While AS 6518 A is still in progress, it will use both UCS_DM and UCS_DM_A to handle the transition from the ‘Observable-Measurement-Coordinate. Tuple’ scheme to the new ‘Quantity-Value. Type’ scheme. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Domain Data Model UCS UML Profile Example – UCS_DM_A Quantities Walkthrough in model.

UCS Domain Data Model UCS UML Profile Example – UCS_DM_A Quantities Walkthrough in model. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Domain Data Model UCS_DM_A Quantities and Real Number Fastpilot, Inc 2018, some rights

UCS Domain Data Model UCS_DM_A Quantities and Real Number Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Products: Components and Configurations of Components A UCS Component: • Implements and exposes

UCS Products: Components and Configurations of Components A UCS Component: • Implements and exposes at least one UCS Service. Interface in at least one role: producer, consumer, mediator, proxy, etc. • Provides or requires all of the interfaces specified by each Service. Interface. • Publishes a UCS Product Service Description that includes an ICD for each implemented interface. A UCS Configuration: • Contains one or more UCS Components. • Publishes a UCS Product Service Description that includes the UCS Produce Service Description for each UCS Component and a Configuration description describing how the UCS Components are used together. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

 • • UCS Product UCS Configuration UCS Component UCS System This is an

• • UCS Product UCS Configuration UCS Component UCS System This is an excerpt from a schema for a UCS Product Registry and Package Repository design. See UCS-REPECHGOV. eap in the Tutorial 01 folder Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Product Example - Flight. Status • Imagine a new reconnaissance UAV with project

UCS Product Example - Flight. Status • Imagine a new reconnaissance UAV with project name Far. See. • The Far. See project commits to providing a UCS AS 6518 A Vehicle. Flight. Status provider service interface in the delivered UAV that will interoperate with an UCS AS 6518 A Vehicle. Flight. Status consumer. • The system integrator commits to implementing a UCS AS 6518 A ~Vehicle. Flight. Status consumer service interface in the Ground Control Station (GCS) that will interoperate with any UCS AS 6518 A Vehicle. Flight. Status providers. • In the operational system, there will be at least two UCS Products, either UCS Components or UCS Configurations, that: • Implement the ~Vehicle. Flight. Status consumer service interface on the GCS side. • Implement the Vehicle. Flight. Status provider service interface on the UAV side. • These UCS Products will provide UCS Service Descriptions (perhaps as an ICD) that allow the UAV provider and GCS integrator to use a UCS standard Flight Status capability. • UCS Products may have non-UCS, proprietary, or program-specific capabilities and interfaces. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Far. See Vehicle Flight Status Overview • The Vehicle. Flight. Status provider service interfaces

Far. See Vehicle Flight Status Overview • The Vehicle. Flight. Status provider service interfaces are exposed by system components that may provide other non-UCS capabilities. • Internal implementation of UCS service interfaces is not relevant. Standard practices apply. (See example in Backup Content. ) • This example assumes: • standalone Vehicle. Flight. Status consumer component that supports a legacy interface on a GCS. • embedded Vehicle. Flight. Status provider component within an airborne aircraft component. • All UCS service interfaces must be exposed and documented to for verification. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Argus. Air. Vehicle. Monitor and Far. See. Air. Vehicle components are both UCS Products,

Argus. Air. Vehicle. Monitor and Far. See. Air. Vehicle components are both UCS Products, each consisting of a single UCS Component. UCS SOA . See Far. See. System. eap in the Tutorial 01 folder Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Services and Interoperability Components that correctly implement UCS Service Interfaces on a common

UCS Services and Interoperability Components that correctly implement UCS Service Interfaces on a common operating platform are more likely to integrate at low cost and interoperate with minimal modifications. Conformance is not a guarantee of interoperability, but the more strict the conformance specifications, and the better the verification process, the greater the likelihood of ‘plug and play. ’ In the example: • The Argus. Air. Vehicle. Monitor can monitor any UAV that exposes a UCS AS 6518 A Vehicle. Flight. Status Service port in the same operating environment. • The Far. See. Air. Vehicle can be monitored by any Control System component that implements a UCS Release AS 6518 A Vehicle. Flight. Status Request port in the same operating environment. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

AS 6518 A Version Control and CM • In Enterprise Architect, a single model

AS 6518 A Version Control and CM • In Enterprise Architect, a single model project file can contain hundreds of managed packages across many Version Control servers and Repositories. • Individual packages can be separately controlled by binding to an external file. Those package XMI files can be managed or not managed as desired. Good for sandbox packages. • A fat-fingered mistake can result in days of recovery and cleanup, BUT the model can be recovered to a recent, consistent state. • At one point in its history, the UCS team decided to version control every package in the model. Currently we do medium-grain package VC, but have not yet rolled back the huge number of small controlled packages. • In the model you are working with today, there are 1348 packages. • It is possible, if you interleave package edits with package checkouts and checkins to produce very complicated errors and inconsistencies. • We ask that all committers use the “EA with SVN” work instruction and its ’ 12 step process’ rigorously. Model walkthrough: Version Control settings and Package Configurations. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Q&A / Discussion Open questions: Followup Topics: Actions: Fastpilot, Inc 2018, some rights reserved.

Q&A / Discussion Open questions: Followup Topics: Actions: Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Backup Content • UCS Caveats for UML Modelers • UCS Receptions Modeled as Operations

Backup Content • UCS Caveats for UML Modelers • UCS Receptions Modeled as Operations • Interpreting UCS Service. Interface Receptions • Protocols: Activity Diagrams vs. State Machines. • Mapping Message Models to Domain Data Models Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS Caveats for UML Modelers The UCS WG explicitly decided against establishing UML 2

UCS Caveats for UML Modelers The UCS WG explicitly decided against establishing UML 2 as a requirement. The team tried to stay compliant as much as possible, but there a few cases where the UCS model cannot be interpreted per strict UML 2. • There is widespread use of attributes typed by Classes. However, the semantics of these cases are NOT strict Composition. Treat these cases as one-way navigable associations. • Service. Interface Operations should be interpreted as Receptions. All UCS interfaces use asynchronous signaling semantics, NOT call semantics. (Protocol Activity diagrams define the Message Exchange Pattern (MEP) for each interface, so call semantics can be defined where required. ) • At the Conceptual level, the <<Projection>> connector extends UML Association, but it does not have UML Association semantics. (At the Logical/ICD level, the <<Projection>> connector is a UML Association. ) Fastpilot, Inc 2018, some rights reserved. UCS Introduction

UCS AS 6518 A Receptions Modeled as Operations Fastpilot, Inc 2018, some rights reserved.

UCS AS 6518 A Receptions Modeled as Operations Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Interpreting UCS Service. Interface Receptions Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Interpreting UCS Service. Interface Receptions Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Protocols: Activity Diagrams vs. State Machines. • Protocol indicates that a get. UCSOperation. Procedure

Protocols: Activity Diagrams vs. State Machines. • Protocol indicates that a get. UCSOperation. Procedure signal arrives on the Operational Procedure Request interface, • Then, sequentially/consequentially, a send. UCSOperational. Procedure signal arrives on the Operational Procedure Response interface. • This protocol provides simple “call semantics” using asynch signals. • What are specifics for each role: requester (client) and responder (server)? Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Protocols: State Machines State machines allow for more precision re: protocol. In this example,

Protocols: State Machines State machines allow for more precision re: protocol. In this example, we show that the client role is expected to retry if a request times out. Timeout and retry are important mechanisms to prevent deadlock or non-progress on protocols. (In R 3. 2 Release cycle, the UCS WG determined to use State Machines in some future release. ) Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Implementing Service Interfaces in Components Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Implementing Service Interfaces in Components Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Mapping Message Models to Domain Data Models Data exchanges within a system can happen

Mapping Message Models to Domain Data Models Data exchanges within a system can happen via messages, or via shared database access, or both. The use of queries like SQL SELECT or UPDATE statements are well understood and covered by any basic introduction to database systems. Due to the message-intensive nature of the architectures we are working with, mapping message definitions to the domain data model is an important consideration. In the next set of slides we will walk through an example of how messages about generic tracks can be defined relative to a domain data model. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Simple Track / Operating Picture Example In this domain data model fragment, a ‘relevant

Simple Track / Operating Picture Example In this domain data model fragment, a ‘relevant operating picture’ has associated a set of tracks. Each track may be part of a correlated set of tracks identifying a single track. We want to exchange messages that talk precisely about this view of the operational environment. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Simple ROP Information Message Per earlier discussion, remember that the reference to a Relevant.

Simple ROP Information Message Per earlier discussion, remember that the reference to a Relevant. Operating. Picture instance given by ‘rop’ is a property of the message. How that reference is encoded in the message is a platform decision. ROPInfo message: Simple Select from Operating Picture derive: self. position = rop. position and self. extent = rop. extent No need to put query specification in projection rolename, just use the projection rolename ‘rop’ in the UML-OCL statement. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Simple Track Info The Track. Info message simply reports the current position of a

Simple Track Info The Track. Info message simply reports the current position of a specific track. The Track. Info references a specific track by its identifier. In this example, we capture the reference explicitly as a <<key>> attribute containing the track. ID of the referenced track. Note that we may wish to defer decision about the ‘identity and reference’ mechanism until later, if it is not mandated for interoperability across systems. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Qualified Track Info Message Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Qualified Track Info Message Fastpilot, Inc 2018, some rights reserved. UCS Introduction

OCL message specifications have equivalent SQL versions inv: self. position = rop. position and

OCL message specifications have equivalent SQL versions inv: self. position = rop. position and self. extent = rop. extent SELECT rop, position, extent FROM Relevant. Operating. Picture r WHERE r. rop = <some rop ID> The limitation of using SQL is that it requires the domain data model to be in some ‘relational’ model form, and a specific mechanism for identity and reference (for primary, secondary, and foreign keys) must be locked in. In database technology, any ‘view’ of a database can be defined using a query. This is why you may run into cases where message specifications in message models are called ‘views’ or ‘view specifications’. Fastpilot, Inc 2018, some rights reserved. UCS Introduction

Defining messages per the domain data model. Keep in mind going forward that every

Defining messages per the domain data model. Keep in mind going forward that every message must have unambiguous meaning with respect to the operational domain. Natural language documentation can be notoriously incomplete, inconsistent, and incorrect. If the operational domain is defined using a domain data model, it is possible to formally define messages with respect to the domain data model. If the domain data model is known to be relational (e. g. as a platform specific model), can use SQL SELECT and UPDATE statements to define messages. If the domain model is platform independent, use the OMG Object Constraint Language (OCL), which is formal and well-supported with production-quality tooling. (Cameo yes, Enterprise Architect, no). With a common domain data model, messages or message sets defined with respect to that domain data model will always have interoperability at the semantic level (e. g. what a message element or field means). Fastpilot, Inc 2018, some rights reserved. UCS Introduction