What Is Architectural Data?

Architectural data is a centralized definition of interfaces, data types, system constants, and platform-specific data that you can use throughout an entire system design hierarchy. It is independent of component and subcomponent models.

In the following image, two component models have an interface, SensorInterface, defined in the Architectural Data section that are assigned to Bus Element ports in the component models.

Architectural data can include:

• Port interfaces and elements, such as:

  • Data interfaces and their elements

  • Service interfaces and their functions and function arguments

  • Physical interfaces and their elements

• Data types, such as:

  • Alias types

  • Numeric types

  • Value types

  • Enumerated data types

  • Struct types and their elements

• System-wide constants

• Platform-specific elements, such as:

  • Software address methods

  • AUTOSAR Classic properties on interfaces and constants

  • Custom stereotypes

All data dictionaries have an Architectural Data section and a Design Data section. You can move interfaces and data types between the Design Data and Architectural Data sections. Design data contains locally stored data types within the model, variables and data types that define parameters, signals, and local component data that determine the behavior of a model. The Design Data section can store only certain classes and data types. See Valid Design Data Classes for more information. For more information about data dictionaries, see What Is a Data Dictionary? To edit the data in the Architectural Data section of a data dictionary, use the Architectural Data Editor or the programmatic interface Simulink.dictionary.ArchitecturalData.

When to Use Architectural Data

Use the Architectural Data section to store centralized definitions for interfaces, data types, constants, and platform-specific data. For example, use the Architectural Data section in these situations:

• You are creating interfaces that are used to explicitly define the exchange of information that can be requested or provided by architectures and component models.

• You are using architectures created with System Composer™ and storing your interface definitions in a linked data dictionary.

• You intend to deploy your work to standardized platforms such as the AUTOSAR Classic and AUTOSAR Adaptive platforms. For more information regarding AUTOSAR-specific architectural data workflows, see Graphically Manage AUTOSAR Architectural Data (AUTOSAR Blockset).

• You are using external artifacts generated with third-party tools, such as interface control documents and imported ARXML files, to manage custom metadata.

Benefits of Using Architectural Data

Using architectural data provides these capabilities and benefits.

Architectural Data Section Capability	Benefits
Standalone data authoring	Architectural data and its authoring tools allow you to design interfaces and data types at the system level of a design hierarchy at any point in your architecture workflow, either, before or after you create your subcomponent models, software component models, and applications. Architectural data eliminates the need to redefine and maintain multiple interface and data type definitions that are identical across applications.
Data access	Any model linked to the data dictionary can access data stored in the Architectural Data section. This includes all additional metadata, such as custom profiles and AUTOSAR properties.
Using domain-specific terminology for port interfaces	You can use physical interfaces in Simscape™ diagrams to define the interfaces of physical ports and their connections. Service interfaces are used to define services in client-server communication architectures. Services consist of functions and their arguments, and facilitate the processing and transmission of data with their clients. Data interfaces are semantically equivalent to Simulink.Bus objects, but the configuration workflow for architectural data interfaces has fewer steps and extends domain-specific terminology to interfaces, their elements, data types, and constants.
Accessing platform-specific properties	Platform-specific properties are centrally accessible from the Architectural Data sections of data dictionaries. Platform-specific properties are available on the definition of the architectural data object. Code generation and deployment workflows are supported for the Architectural Data section, allowing management of architectural interfaces, data types, constants, and other platform-specific data elements without needing to create a model or associated component.
System-wide constant definition	You can define system constants with a data types, names, numeric values, and descriptions in one location that is accessible by multiple models, blocks, variant condition expressions, parameters, stereotypes, and more, across a design hierarchy. To define system constants use the Simulink.dictionary.archdata.Constant object or use the Architectural Data Editor.
Metadata, data analysis, property filtering	Port interfaces, data types, and system constants defined in the Architectural Data section enable the use of metadata used for deployment, analysis, and filtering of data based on property information.
Importing architectural data from external artifacts	When using external artifacts generated with third-party tools, such as interface control documents and ARXML files, you can import custom metadata and apply it to port interfaces in the Architectural Data section.