SAE AS 6522-2016 Unmanned Systems (UxS) Control Segment (UCS) Architecture Architecture Technical Governance.pdf

《SAE AS 6522-2016 Unmanned Systems (UxS) Control Segment (UCS) Architecture Architecture Technical Governance.pdf》由会员分享，可在线阅读，更多相关《SAE AS 6522-2016 Unmanned Systems (UxS) Control Segment (UCS) Architecture Architecture Technical Governance.pdf（85页珍藏版）》请在麦多课文档分享上搜索。

1、_SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising theref

2、rom, is the sole responsibility of the user.”SAE reviews each technical report at least every five years at which time it may be revised, reaffirmed, stabilized, or cancelled. SAE invites your written comments and suggestions.Copyright 2016 SAE InternationalAll rights reserved. No part of this publi

3、cation may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE.TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada)Tel: +1 724-776-4970 (out

4、side USA)Fax: 724-776-0790Email: CustomerServicesae.orgSAE WEB ADDRESS: http:/www.sae.orgSAE values your input. To provide feedback on thisTechnical Report, please visithttp:/standards.sae.org/AS6522AEROSPACESTANDARDAS6522Issued 2016-12Unmanned Systems (UxS) Control Segment (UCS) Architecture:Archit

5、ecture Technical GovernanceRATIONALEThis document is the SAE publication of the Department of Defense UAS Control Segment (UCS) Architecture: Architecture Technical Governance Version 2.5 (PR) approved for Distribution A public release 15.S-1859.INTRODUCTIONThis UCS architecture technical governance

6、 identifies the technical policies, processes, and standard definitions for use by the SAE AS-4UCS Technical Committee. It provides overall guidance on compliance with internal and external standards adopted by AS-4UCS. This specification identifies the modeling languages, and provides a set of poli

7、cies and procedures on creation of model artifacts, while providing standard definitions for major elements of the architecture. The core audiencefor this document is the AS-4UCS Technical Committee.This specification does not establish the normativeness of the UCS Architecture Model for UCS product

8、s. The required conformance of UCS products to the UCS Architecture is specified in UxS Control Segment (UCS) Architecture: Conformance Specification, AS6513.APPLICABILITYThis document applies to the Unmanned Systems (UxS) Control Segment (UCS) Architecture: Model AS6518 produced for SAE AS4-UCS Arc

9、hitecture. Any references in this document to “Architecture Release” or “UCS Architecture Release” refer to revisions detailed in the Unmanned Systems (UxS) Control Segment (UCS) Architecture: Architecture Description AS6512.SAE INTERNATIONAL AS6522 Page 2 of 85TABLE OF CONTENTS1. SCOPE 62. REFERENC

10、ES 62.1 References 62.2 Definitions . 72.3 Acronyms 83. ADOPTED STANDARDS, PROCESSES, AND ARTIFACTS 94. OVERVIEW OF THIS DOCUMENT 95. CONFORMANCE 106. TECHNICAL GOVERNANCE POLICIES . 106.1 UCS-TECHGOV-POLICY Architecture Package Structure 106.1.1 Conformance to Policy 106.1.2 Model File Package Stru

11、ctures . 106.1.3 Model Description . 116.2 UCS-TECHGOV-POLICY OMG SoaML Model 146.2.1 Conformance to Policy 146.2.2 Description 146.3 UCS-TECHGOV-POLICY SOA Participant Diagram 156.3.1 Conformance to Policy 156.3.2 Description 156.3.3 Where Used 166.3.4 Constraints 166.3.5 Semantics . 176.3.6 Exampl

12、e 176.4 UCS-TECHGOV-POLICY SOA Participant Architecture Diagram . 186.5 UCS-TECHGOV-POLICY SOA Service Architecture Diagram 186.6 UCS-TECHGOV-POLICY CDM Projection Stereotype 186.7 UCS-TECHGOV-POLICY LDM Refine Stereotype 186.8 UCS-TECHGOV-POLICY UML Class Diagram 186.8.1 Conformance to Policy 186.8

13、.2 Description 186.8.3 Where Used 186.8.4 Constraints 196.8.5 Semantics . 196.8.6 Examples 206.9 UCS-TECHGOV-POLICY SOA Class Implementation Diagram 206.10 UCS-TECHGOV-POLICY UML Use Case Diagram. 206.10.1 Conformance to Policy 206.10.2 Description 206.10.3 Where Used 206.10.4 Constraints 216.10.5 S

14、emantics . 216.10.6 Examples 226.11 UCS-TECHGOV-POLICY UML Use Case to Interface Trace Matrix . 256.11.1 Conformance to Policy 256.11.2 Description 256.11.3 Where Used 256.11.4 Constraints 266.11.5 Semantics . 266.11.6 Example 266.12 UCS-TECHGOV-POLICY UML Activity Diagram . 266.12.1 Conformance to

15、Policy 266.12.2 Description 276.12.3 Where Used 276.12.4 Constraints 27SAE INTERNATIONAL AS6522 Page 3 of 856.12.5 Semantics . 286.12.6 Examples 286.13 UCS-TECHGOV-POLICY UML Sequence Diagram 296.13.1 Conformance to Policy 296.13.2 Description 296.13.3 Where Used 296.13.4 Constraints 306.13.5 Semant

16、ics . 316.14 UCS-TECHGOV-POLICY SOA Services Architecture Diagram. 326.14.1 Conformance to Policy 326.14.2 Description 326.14.3 Where Used 336.14.4 Constraints 336.14.5 Semantics . 346.14.6 Example 346.15 UCS-TECHGOV-POLICY SOA States and Modes Diagrams 356.15.1 Conformance to Policy 356.15.2 Descri

17、ption 356.15.3 Where Used 356.15.4 Constraints 366.15.5 Semantics . 366.15.6 Examples 376.16 UCS-TECHGOV-POLICY Naming Conventions 386.16.1 Conformance of Policy 386.16.2 Description 386.16.3 Where Used 386.16.4 Constraints 386.17 UCS-TECHGOV-POLICY UCS Service Contract and Non-functional Property M

18、odel 436.17.1 Conformance to Policy 436.17.2 Description 436.18 UCS-TECHGOV-POLICY Instruction for Specific Model Element Definitions . 456.18.1 Conformance to Policy 456.18.2 Description 456.18.3 Where Used 486.18.4 Constraints 486.18.5 Semantics . 486.18.6 Examples 486.19 UCS-TECHGOV-POLICY Namesp

19、ace. 536.19.1 Conformance to Policy 536.19.2 Description 536.19.3 Where Used 536.19.4 Contraints 536.19.5 Semantics . 536.19.6 Example 536.20 UCS-TECHGOV-POLICY UML 546.20.1 Conformance to Policy 546.20.2 Description 546.20.3 Where Used 546.20.4 Semantics . 546.21 UCS-TECHGOV-POLICY Protocol Activit

20、y Diagram 546.21.1 Conformance to Policy 546.21.2 Description 556.21.3 Where Used 556.21.4 Constraints 556.21.5 Semantics . 556.21.6 Examples 566.22 UCS-TECHGOV-POLICY UCS Data Model Diagram 576.22.1 Conformance to Policy 576.22.2 Description 576.22.3 Where Used 57SAE INTERNATIONAL AS6522 Page 4 of

21、856.22.4 Constraints 576.22.5 Semantics . 576.23 UCDSWGUCS-TECHGOV-POLICY UCS MODEL Rules of Construction 626.23.1 Conformance to Policy 626.23.2 Description 626.23.3 Where Used 626.23.4 Contraints 626.23.5 Semantics . 626.24 UCS-TECHGOV-POLICY Coordinate Reference Systems and Reference Frames 686.2

22、4.1 Conformance to Policy 686.24.2 Description 686.24.3 Where Used 686.24.4 Constraints 686.24.5 Semantics . 687. UCS PROCESSES . 757.1 UML Class Diagram Process Instruction 757.1.1 Overview . 757.1.2 Process for Creating UML Class Diagrams 757.1.3 After Example 787.2 ServicesArchitecture Diagram Pr

23、ocess Instruction. 797.2.1 Overview . 797.2.2 When to Create ServicesArchitecture Diagrams 797.2.3 Complex Example - L2 797.2.4 L2 Sequence Diagram - Release UAV Resource. 797.2.5 Project Browser View after Adding Collaboration Diagram - L2 . 807.2.6 L2 Services/Architecture Diagram - L2 Release UAV

24、 Resource Collaboration 807.2.7 Complex Example continued - L3 . 818. NOTES 858.1 Revision Indicator 85FIGURE 1 AS6518.EAP PACKAGE STRUCTURE . 10FIGURE 2 AS6518.EAP PACKAGE STRUCTURE . 11FIGURE 3 UCS SOAML UML PROFILE 14FIGURE 4 LOCATION AND LEVEL OF A SOA PARTICIPANT DIAGRAM 16FIGURE 5 SOA PARTICIP

25、ANT DIAGRAM EXAMPLE 17FIGURE 6 UML CLASS DIAGRAM LOCATION 19FIGURE 7 UML CLASS DIAGRAM EXAMPLE 20FIGURE 8 USE CASE DIAGRAMS LOCATION 21FIGURE 9 USE CASE DIAGRAM EXAMPLE 1 . 22FIGURE 10 USE CASE DIAGRAM EXAMPLE 2 . 23FIGURE 11 USE CASE DIAGRAM EXAMPLE 3 . 24FIGURE 12 USE CASE TO INTERFACE TRACE EXAMP

26、LE . 26FIGURE 13 LOCATION OF ACTIVITY DIAGRAMS 27FIGURE 14 ACTIVITY DIAGRAM EXAMPLE 1 . 28FIGURE 15 ACTIVITY DIAGRAM EXAMPLE 2 . 29FIGURE 16 UML SEQUENCE DIAGRAM LOCATION 30FIGURE 17 UML SEQUENCE DIAGRAM EXAMPLE 1 31FIGURE 18 UML SEQUENCE DIAGRAM EXAMPLE 2 32FIGURE 19 LOCATION OF SERVICESARCHITECTUR

27、E DIAGRAMS 33FIGURE 20 L3 SERVICESARCHITECTURE DIAGRAM EXAMPLE. 34FIGURE 21 L2 SERVICESARCHITECTURE DIAGRAM EXAMPLE. 35FIGURE 22 LOCATION OF SYSTEM STATES AND MODES DIAGRAM 36FIGURE 23 SYSTEM STATES AND MODES DIAGRAM 37FIGURE 29 SYSTEM STATES AND MODES DIAGRAM (CONTINUED). 38FIGURE 24 NORMALIZATION

28、OF ELEMENT NAMES WITHIN A PACKAGE. 41FIGURE 25 UCS SERVICE CONTRACT AND NON-FUNCTIONAL PROPERTY METAMODEL 44FIGURE 26 LOCATION OF PROTOCOL ACTIVITY DIAGRAMS. 55FIGURE 27 PROTOCOL ACTIVITY DIAGRAM EXAMPLE 1 56FIGURE 28 PROTOCOL ACTIVITY DIAGRAM EXAMPLE 2 57SAE INTERNATIONAL AS6522 Page 5 of 85FIGURE

29、29 AIRPRESSUREREPORT EXAMPLE DIAGRAM . 59FIGURE 30 LOCATION OF THE REFINEMENTS AND REFINED ELEMENT VIEWS PACKAGES . 61FIGURE 31 SCRIPTING VIEW IN EA 63FIGURE 32 AS6518 MODEL RELATIONSHIPS 64FIGURE 33 UCS_DM DATA MODEL UML PROFILE . 71FIGURE 34 EXAMPLES OF CONSTRAINED PRIMITIVE TYPES . 72FIGURE 35 EX

30、AMPLE OF SIMPLE SPATIAL REFERENCE POSITION3D. 73FIGURE 36 EXAMPLE OF SIMPLE SPATIAL REFERENCE WITH TIME 74FIGURE 37 EXAMPLE OF UCS MEASUREMENT . 75FIGURE 38 7.1.3.1 PROJECT BROWSER VIEW . 78FIGURE 39 UML CLASS DIAGRAM 78FIGURE 40 L2 SEQUENCE DIAGRAM . 79FIGURE 41 PROJECT BROWSER VIEW AFTER ADDING CO

31、LLABORATION DIAGRAM 80FIGURE 42 L2 SERVICES/ARCHITECTURE DIAGRAM 80FIGURE 43 L3 SEQUENCE DIAGRAM . 81FIGURE 44 PROJECT BROWSER VIEW AFTER ADDING COLLABORATION DIAGRAMS . 81FIGURE 45 L3 SERVICESARCHITECTURE DIAGRAM. 82FIGURE 46 BEFORE REPOSITIONING PARTICIPANT INSTANCES. 84FIGURE 47 AFTER REPOSITIONI

32、NG PARTICIPANT INSTANCES 84FIGURE 48 EXAMPLE OF COLLABORATION DIAGRAM . 85TABLE 1 APPROPRIATE ENUMERATION DEFINITIONS. 47TABLE 2 INAPPROPRIATE ENUMERATION DEFINITIONS . 48TABLE 3 PROJECTION CONNECTOR GUIDELINES 60TABLE 4 AS6518 MODEL RULES OF CONSTRUCTION 65TABLE 5 RULES OF CONSTRUCTION SCRIPTS . 68

33、TABLE 6 COMPARISON OF SPATIAL AND NON-SPATIAL METATYPES. 69SAE INTERNATIONAL AS6522 Page 6 of 851. SCOPEThe UCS technical governance comprises a set of policies, processes, and standard definitions to establish consistency and quality in the development of architecture artifacts and documents. It pr

34、ovides guidance for the use of adopted industry standards and modeling conventions in the use of Unified Modeling Language (UML) and Service Oriented Architecture Modeling Language (SoaML), including where the UCS Architecture deviates from normal UML conventions.This document identifies the definin

35、g policies, guidelines, and standards of technical governance in the following subjects:xIndustry standards adopted by the AS-4UCS Technical Committee: These are the industry standards and specifications adopted by AS-4UCS in the generation and documentation of the architecture.xUCS Architecture Dev

36、elopment: UCS specific policies on the development of the UCS Architecture.The AS-4UCS Technical Committee governance policies are intentionally minimal. The object is to provide direction specific to the intent and scope of developing architecture artifacts that follow a consistent set of specifica

37、tions and industry best practices.Standards are referenced within policies. Standards may place constraints on policies that are implemented by processes. Each process is intended to guide the development of architecture artifacts. For example, a standard may dictate that a UML diagram be modeled in

38、 a particular methodology using only approved stereotypes from the SoaML UML profile.UCS technical governance applies to the following technical work products that are generated within the AS-4UCS Technical Committee. It is not applicable to third party developers, programs, or any other consumer of

39、 the UCS Architecture.xThe technical governance applies to the following item:o UxS Control Segment (UCS) Architecture: Model AS6518: Structure, diagrams, packages, and artifacts shall be defined in individual policies.NOTE: Examples in this document are correct per UxS Control Segment (UCS) Archite

40、cture: Architecture Technical Governance AS6522 content but may not necessarily reflect the latest revision of the UCS Architectural Model.2. REFERENCES2.1 ReferencesNOTE: For a complete reference for each UCS Architecture work product listed below (including date and version number) refer to the Ve

41、rsion Description Document, AIR-6520, included with this release.DoD (U.S. Department of Defense). 2009. FY2009-2034 Unmanned Systems Integrated Roadmap. At http:/www.acq.osd.mil/sts/docs/UMSIntegratedRoadmap2009.pdfOGC. 2010. The OGC Abstract Specification Topic 2: Spatial referencing by coordinate

42、s, Open Geospatial Consortium Inc. 27 April 2010, OGC 08-015r2 Version 4.0.0OMG (Object Management Group). 2012. Service Oriented Architecture Modeling Language (SoaML). Version 1.0.1. May 2012. At http:/www.omg.org/spec/SoaML/1.0.1.2011. Unified Modeling Language (UML). Version 2.4.1. August 2011.

43、At http:/www.omg.org/spec/UML/2.4.1/.SAE Unmanned Systems (UxS) Control Segment (UCS) Architecture: Architecture Description. AS6512: AS-4UCS Technical Committee.SAE Unmanned Systems (UxS) Control Segment (UCS) Architecture: Conformance Specification. AS6513: AS-4UCS Technical Committee.SAE INTERNAT

44、IONAL AS6522 Page 7 of 85SAE Unmanned Systems (UxS) Control Segment (UCS) Architecture: Interface Control Document (ICD). AIR6514: AS-4UCS Technical Committee.SAE Unmanned Systems (UxS) Control Segment (UCS) Architecture: Data Distribution Service (DDS). AIR6521: AS-4UCS Technical Committee.SAE Unma

45、nned Systems (UxS) Control Segment (UCS) Architecture: Model. AS6518: AS-4UCS Technical Committee.2.2 DefinitionsDOMAIN: A discrete subject matter within an architecture model.MESSAGE: The interface structure that resides in the UCS Domain Participant Model. The interfaces contain messages that are

46、represented by MessageType . The MessageType and their parameters reside in the Information Model. The final, refined, representation of messages is found in the Information Model/Logical Data Model/UCS package. The format of the message when transmitted is left to service implementation, including

47、choices such as protocol and associated format requirements.NON-FUNCTIONAL PROPERTIES (NFPs): The usability, reliability, performance, scalability, safety and security aspects of how the system must execute functional requirements.PLATFORM INDEPENDENT MODEL (PIM): An architecture view of a System-of

48、-Interest from the platform independent viewpoint. A PIM exhibits a specified degree of platform independence so as to be suitable for use with different platforms.PLATFORM SPECIFIC MODEL (PSM): An architecture view of a system from the platform specific viewpoint.REQUIREMENT: A statement that clear

49、ly identifies what must be done in order to realize specific objectives under a given set of conditions.There are three basic types of requirements: functional, performance, and constraint.xfunctional requirement: Specifies the task, action, or activity (i.e., function) that must be accomplished.xperformance requirement: Specifies how well the function must be performed and under what conditions.xconstraint: Specifies the l