Purpose of this introduction.

1. Unmanned Systems (UxS) Control Segment (UCS) Architecture ModelAS6518A – pre-releaseTutorial 01Jim AlbersSecretary, SAE AS-4 UCS ArchitectureChair AS-4 UCS-1 UCS Architecture User GroupFastpilot, 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.

2. 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 how to navigate the model in EA using EA tools and UCS add-on scripts. Introduce basic scripting and model query tools.

3. UCS Introduction Outline Open Architecture and UCS Downloading UCS Architecture Release A (AS6518A) 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 • PrimitiveTypes and Constrained PrimitiveTypes • AS6969 Quantities and UCS realizations. UCS Product examples: • UCS Component – VehicleFlightStatus service provider • UCS Component – VehicleFlightStatus service consumer Backup material

4. Download UCS Architecture Pre-Release AS6518A 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/committeeHome.do?comtID=TEAAS4UCS • In the AS4UCS 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. r1873) • 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

5. The UCS Architecture Has Multiple Parts The whole of the UCS Architecture is referenced using the part number of the UCS Architecture Description – AS6512A The UCS Architecture document tree shows the relationships of the standards in the architecture. AS6518A MODEL is the set of architectural models delivered as an Enterprise Architect project file. The AS6969 Data Dictionary for Quantities used in Cyber Physical Systems is not part of the UCS Architecture, but is foundational for it.

6. Architecture Description AS6512A Version Description Document AIR6520A AS6512A Document Tree Architecture Technical Governance AS6522A Model AS6518A UCS Architectural Model Package System Use Case Model Package Use Case Trace (UCTRACE) AIR6519A Domain Participant Model Package Service Contract and NFP Model Package Information Model Package Conformance Specification AS6513A References: AS6969 Data Dictionary of Quantities used in Cyber Physical Systems

7. 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.

8. 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 ServiceInterfaces 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.

9. 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.

10. Messages are defined by Domain Data Domain model for MissionTasks and Vehicles Message Mapping via “Projection” We will be looking at this in greater detail.

11. The UCS SOA: Avoids constraints on component architecture. Design, adapt, or re-use 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 (SoaML) profile for UML. • See AS6522A for details on UCS use of SoaML concepts and metamodel. • See Appendix A in the OMG SoaML specification for detailed mapping of SoaML v1.0.1 to the OASIS Reference Model.

12. 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 AS6969 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/MagicDraw).

13. 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 • ServiceInterfaces – set of interfaces required to employ a service plus protocol Message Model – definition of messages exchanged over ServiceInterface Interfaces Domain Data Model – a description of the operational world: entities, their relationships, and their attributes. Define data referenced in Interface messages

14. UCS Conceptual and Logical Model Relationships a.k.a. ‘Domain Participant Model Projection UCS Conceptual Service Model UCS Conceptual Message Model UCS Conceptual Domain Data Model Conceptual Properties Transform Transform TypeRef TypeRef Transform Refine Realize Projection Logical Value Types UCS Logical Service Model UCS Logical Message Model UCS Logical Domain Data Model TypeRef TypeRef 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.

15. Transform Conceptual / Logical relationships. The wiring. TypeRef Transform Projection Transform Realize Refine TypeRef Generated via transforms

16. Implementers: Use the Logical Models. Use the Logical Service, Message, and Domain Data models to design and build UCS Architecture conformant products. Work withAS6518A 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 AS6518A Conceptual Models are the factory: with complex assembly jigs, scaffolding, wiring, and production processes. The AS6518A Logical Model is generated from the Conceptual Model by substituting complete definitions for conceptual quantity types. In AS6518A, the Logical Model is the basis for UCS Conformance, details to be documented in AS6522A Technical Governance and AS6513 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.)

17. AS6518A Model Organization Conceptual Model • Service Model • Message Model • Domain Data Model Logical Model • Service Model • Message Model • Domain Data Model Extensions to AS6518A (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.) 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.

18. AS6518A Extensions Mirror Model Structure • Extension elements reference read-only Core elements via: • Generalization/Specialization • Realization • Refinement • Dependency • Diagram Views • Extension packages are integrated into the EA project, but managed in separate VC repositories.

19. Detailed examination of the submodels. Service Model - SOA Service Models using SoaML, 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 MessageType 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.

20. UCS Service Model UCS Service Model Overview For historical reasons the Conceptual Service Model is labeled “Domain Participant Model” Defines UCS SOA ServiceInterfaces 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 (SoaML), which realizes the OASIS SOA Reference Architecture.

21. UCS Service Model UCS Service Model: Vehicle Flight Control • EA Does not recognize isConjugate property on ports, so must explicitly define the ~VehicleFlightControlServiceInterface. • EA Will not automatically expose ServiceInterface Provided and Required interfaces so must add by hand (and check). Model walkthrough: navigating across models.

22. UCS Service Model UCS Service Model: Participant Interactions All elements in this diagram link to the core model. Nothing is ‘drawn’.

23. UCS Service Model UCS Service Model: Protocol Example • In UCS AS6518A protocols are specified using UML Activity diagrams. • This example shows that VehicleFlightControl service supports familiar ‘call semantics’ using a pair of request/response interfaces. • A sessionID attribute is available for all messages to support stateful protocols.

24. UCS Service Model UCS Service Model: Migrating to Protocol Statemachines per JAUS • In UCS AS6518A protocols are specified using UML Activity diagrams, that are not syntactically correct with respect to UML2. 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.

25. JAUS Access Control Protocol This is an example of a real-world control protocol. In your Tutorial 01 folder, open the model JAUS_AccessControl.eap

26. UCS Message Model UCS Message Model: Overview Each UCS Service ‘operation’ is an event reception for a UCS MessageType element. UCS Messages have explicit derivations from the domain data model, given by Projection and refinement in the AS6518A, 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 UCSPersistentView and its specializations in the Data Model.

27. UCS Message Model 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 UML2 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.

28. UCS Message Model Conceptual 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 UML2 Association semantics. Conceptual Domain Data Model

29. UCS Message Model Logical Message Model Model walkthrough: navigating across models, viewing constraints Logical Domain Data Model

30. 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: _vehicleNavigationAction 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.airVehicleFlapAngle = self._vehicleNavigationAction.airVehicleFlapAngle) and (self.landingGearStatus = self._vehicleNavigationAction.landingGearPositionStatus.setPoint) and (self.airVehicleSpeedBrakeAngle = self._vehicleNavigationAction.airVehicleSpeedBrakeAngle.angle)

31. 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 UML2 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.

32. UCS Domain Data Model UCS Domain Data Model Overview PrimitiveTypes • Platform-independent Real, Integer, String, Boolean. (UML PrimitiveTypes plus Real) UCS ConstrainedTypes • PrimitiveTypes with metadata: precision, units, etc. (extended UML PrimitiveType) • Stereotyped by base PrimitiveType <<Real>>, <<String>>, etc. • Designed to support XSD schema element attributes. UCS Conceptual Quantity Types • Quantities defined for Cyber Physical Systems (AS6969) • Linked by UUID to specifications in AS6969. UCS Logical Value DataTypes • Primitive, Enumeration, or Composite types that don’t have identity (UML DataType) • 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.

33. UCS Domain Data Model UCS ConstrainedTypes Tagged values designed for convenient mapping to XSD element attributes. But use is Platform Independent.

34. UCS Domain Data Model UCS Conceptual Quantity Types Conceptual Quantity Types were called “Observables” in previous versions of AS6518. Quantity types in AS6518A are based on the International System of Quantities ISO-80000, with elaboration of semantics in AS6969 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 single-precision, 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 the different realization types.

35. 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 AS6969, 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.

36. UCS Domain Data Model Conceptual Quantities and Logical Value Types Conceptual Domain Data Model Logical Domain Data Model Logical Domain Data Model The WGS84EllipsoidPosition logical value type realizes the conceptual PositionVector quantity with a UML Realization relationship.

37. UCS Domain Data Model Conceptual Quantities and Logical Value Types All AS6969 Quantity specifications are referenced via the AS6969 UUID. These are UML Instances (“InstanceSpecifications”), constant values. Model walkthrough: navigating tagged value refs.

38. UCS Domain Data Model UCS UML Profiles – stereotypes and tagged values. • AS6518A will use three UML profiles: • UCS_DM_A – UCS Data Model profile, revision A • UCS_SoaML – UCS standard subset of SoaML 1.1 with the addition of a version tag for ServiceInterface elements. • UCS_NFP – Very simple profile for working with non-functional property requirements. • While AS6518A is still in progress, it will use both UCS_DM and UCS_DM_A to handle the transition from the ‘Observable-Measurement-CoordinateTuple’ scheme to the new ‘Quantity-ValueType’ scheme.

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

40. UCS Domain Data Model UCS_DM_A Quantities and Real Number

41. UCS Products: Components and Configurations of Components A UCS Component: • Implements and exposes at least one UCS ServiceInterface in at least one role: producer, consumer, mediator, proxy, etc. • Provides or requires all of the interfaces specified by each ServiceInterface. • 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.

42. 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 • UCS Product • UCS Configuration • UCS Component • UCS System

43. UCS Product Example - FlightStatus Imagine a new reconnaissance UAV with project name FarSee. The FarSee project commits to providing a UCS AS6518A VehicleFlightStatus provider service interface in the delivered UAV that will interoperate with an UCS AS6518A VehicleFlightStatus consumer. The system integrator commits to implementing a UCS AS6518A ~VehicleFlightStatus consumer service interface in the Ground Control Station (GCS) that will interoperate with any UCS AS6518A VehicleFlightStatus providers. In the operational system, there will be at least two UCS Products, either UCS Components or UCS Configurations, that: • Implement the ~VehicleFlightStatus consumer service interface on the GCS side. • Implement the VehicleFlightStatus 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.

44. FarSee Vehicle Flight Status Overview • The VehicleFlightStatus 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 VehicleFlightStatus consumer component that supports a legacy interface on a GCS. • embedded VehicleFlightStatus provider component within an airborne aircraft component. • All UCS service interfaces must be exposed and documented to for verification.

45. ArgusAirVehicleMonitor and FarSeeAirVehicle components are both UCS Products, each consisting of a single UCS Component. .See FarSeeSystem.eap in the Tutorial 01 folder UCS SOA

46. 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 ArgusAirVehicleMonitor can monitor any UAV that exposes a UCS AS6518A VehicleFlightStatus Service port in the same operating environment. The FarSeeAirVehicle can be monitored by any Control System component that implements a UCS Release AS6518A VehicleFlightStatus Request port in the same operating environment.

47. AS6518A 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.

48. Q&A / Discussion Open questions: Followup Topics: Actions:

49. Backup Content UCS Caveats for UML Modelers • UCS Receptions Modeled as Operations • Interpreting UCS ServiceInterface Receptions Protocols: Activity Diagrams vs. State Machines. Mapping Message Models to Domain Data Models

50. UCS Caveats for UML Modelers The UCS WG explicitly decided against establishing UML2 as a requirement. The team tried to stay compliant as much as possible, but there are a few cases where the UCS model cannot be interpreted per strict UML2. 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. ServiceInterfaceOperations 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.)