AS6513™
There is sometimes confusion between a UCS service and a UCS product. A UCS service is a capability (to achieve a real world result) that is accessed via a service interface. A UCS product is an end item that can be acquired and managed independently of other UCS products. A UCS product will provide one or more UCS service interfaces. The UCS Architecture does not specify products, but encourages the market-based emergence of software product lines whose visibility is achieved through registries and repositories.
Three types of UCS product are addressed in the UCS Architecture Conformance Specification, AS6513™.
UCS SOFTWARE COMPONENT: A UCS software component is a unit of deployable UCS software that is not further decomposed into other separately managed software components described in a UCS registry or repository. A UCS software component may be as small as a single UCS service participant or as large as a complete UCS domain or collection of UCS domains. Note: a conformant UCS software component will be assigned at least one UCS Architecture Model service package as specified herein.
UCS SOFTWARE CONFIGURATION: A UCS software configuration is a unit of deployable UCS software that comprises multiple UCS software components and/or (separately managed) UCS software configurations described in a UCS registry or repository. Note: a conformant UCS software configuration will be assigned at least one UCS Architecture Model service package as specified herein.
UCS SYSTEM: A UCS system is a physical item that independently satisfies its system-of-interest use cases, has external communication interfaces, and at least one human/machine interface (HMI). UCS systems may include man-portable systems, vehicle-transportable systems, and fixed facilities. UCS systems include UCS software configurations and/or UCS software components. These MAY be described in a UCS product repository or UCS product registry. Note: a conformant UCS system will be assigned at least one UCS service package as specified herein.
UCS product descriptions are the basis for conformance to the UCS Architecture. Notice it is not the product but the product description. Searchable product descriptions are intended to foster a modular open systems approach (MOSA).
AS6513™ requires that a conformant product description includes:
- Product identification/metadata
- Service description for each service
- Required application programming interfaces (APIs)
- Architecture description
- Product test results.
The service description must include a service interface description and a service reachability description. Service interface descriptions must conform to the provided services defined in the service packages of the UCS Architecture Model, AS6518™. If required, users may extend the UCS service packages in accordance with the constraints set out in AS6513™. The service reachability description is system-specific but must include:
- The platform-specific communication protocol/middleware
- The means by which service presence and endpoint are determined
- The means by which service contracts are established, including non-functional properties (NfPs).
UCS-SPEC-RTGPD
Prior to SAE AS-4UCS governance of the UCS Architecture, the OSD UCS Working Group developed a specification to support a standardized and interoperable repository format for UCS product descriptions. This work has not yet been adopted by the SAE, but remains a valuable resource.
The basic concepts of a UCS product are shown in the conceptual model below. A UCS product is a separately managed UCS system or unit of deployable software that may be acquired and used independently of other UCS products. A product description must exist for each released configuration of the product. The description will include UCS product metadata and UCS product artifacts.
In this conceptual model, UCS product conformance verification and UCS product policies are addressed separately from the UCS product description. This recognizes the separate management requirements for this information. Product description artifacts may be maintained by a program; conformance artifacts may be maintained by an independent certification agent; and policy artifacts may be maintained by the management function of the UCS enterprise.
UCS Product Description
In the above conceptual model, a product description comprises product metadata and product artifacts. UCS product metadata is searchable public data about a single UCS product. The metadata supports visibility of UCS products across the UCS enterprise through UCS registries and UCS repositories. There are two types of metadata. Descriptive metadata is the information used to search and locate UCS products; and structural metadata identifies the UCS product artifacts that comprise the UCS product description.
UCS-SPEC-RTGPD requires the following metadata for a UCS product registry or repository:
Technical metadata
- Name of UCS product
- Acronym (optional)
- Product version
- Digital signature (optional)
- UCS product type (i.e. system, software configuration, or software component)
- Description (free text)
- Provenance
- Keywords (optional)
- Security classification
- Provided UCS services
- Other application interfaces
- Required platform API standards
- Available description artifacts (optional)
- Safety certifications
- IA certifications
Business metadata
- Product logo (optional)
- Supplier’s name
- Supplier’s address (optional)
- Supplier’s point of contact
- Supplier’s logo (optional)
- Licensing categories
The required product artifacts for a UCS product repository are:
- UCS product identification and version
- UCS service description
- Software installation instructions and product user guide
- Architecture description document
- System and subsystem ICD (if product is a UCS system)
The required artifacts within a UCS service description are:
- Service interface description
- Behavioral model
- Information model
- Service reachability
- Protocols
- Service presence
- Endpoint
- Service functionality
- Functions
- Service level real world effects
- Technical assumptions
- Service policies and contracts
- Non-functional properties
- UCS conformance and verification records
UCS Product Conformance Artifacts
Associated with each product description will be following artifacts:
- UCS product verification procedure
- UCS product verification reports
UCS Product Policies
Policies establish constraints on the use or maintenance of a UCS product (for example), which may be stated by the provider of the UCS product or by third parties. An agreement to abide by a policy is documented in a contract. Policies may result from technical or business considerations.
Where applicable these artifacts will be available in a UCS repository:
- UCS product policy
- UCS product contract