4 Information requirements

This clause specifies the information requirements for the Assembly functional interface requirement application module. The information requirements are specified as the Application Reference Model (ARM) of this application module.

NOTE 1  A graphical representation of the information requirements is given in Annex C.

NOTE 2  The mapping specification is specified in 5.1. It shows how the information requirements are met by using common resources and constructs defined or imported in the MIM schema of this application module.

This clause defines the information requirements to which implementations shall conform using the EXPRESS language as defined in ISO 10303-11. The following begins the Assembly_functional_interface_requirement_arm schema and identifies the necessary external references.

4.1 Required AM ARMs

The following EXPRESS interface statements specify the elements imported from the ARMs of other application modules.

EXPRESS specification:

*)
USE FROM Altered_part_arm;    --  ISO/TS 10303-1602



USE FROM Functional_specification_arm;    --  ISO/TS 10303-1679



REFERENCE FROM Specification_document_arm    --  ISO/TS 10303-1747
  (get_document_definition);
(*



NOTE 1   The schemas referenced above are specified in the following part of ISO 10303:

Altered_part_arm	ISO/TS 10303-1602
Functional_specification_arm	ISO/TS 10303-1679
Specification_document_arm	ISO/TS 10303-1747

NOTE 2   See Annex C, Figures C.1and C.2 for a graphical representation of this schema.

4.2 ARM type definition

This subclause specifies the ARM type for this application module. The ARM type and definition is specified below.

4.2.1 afir_documented_element_select   

The afir_documented_element_select type is an extension of the documented_element_select type. It adds the data type Protocol_physical_layer_definition to the list of alternate data types.

EXPRESS specification:

*)
TYPE afir_documented_element_select = SELECT BASED_ON documented_element_select WITH
   (Protocol_physical_layer_definition);
END_TYPE;
(*

4.3 ARM entity definitions

This subclause specifies the ARM entities for this module. Each ARM application entity is an atomic element that embodies a unique application concept and contains attributes specifying the data elements of the entity. The ARM entities and definitions are specified below.

4.3.1 Minimally_defined_connector   

A Minimally_defined_connector is a type of Packaged_part whose functionality is defined by a communications protocol. The protocol specifies signal names for each connector terminal and may specify impedance and other electrical characteristics. A Minimally_defined_connector does not specify sufficient information to use the connector in a design, as only the interface terminals and a reference to the physical interface are identified.

NOTE 1   One use for a Minimally_defined_connector is as a reference for a communications protocol.

NOTE 2   The use case for this Application object is primarily to convey the declaration of terminals. The package data usually consists of minimal identification data necessary to find a suitable connector in a catalog so that mating connectors may be identified.

EXPRESS specification:

*)
ENTITY Minimally_defined_connector
  SUBTYPE OF (Packaged_part);
  SELF\Packaged_part.used_package : SET[1:?] OF Package_external_reference;
INVERSE
  terminal : SET[1:?] OF Shape_element FOR associated_definition;
WHERE
  WR1: SIZEOF(SELF\Packaged_part.access_mechanisms) = 0;
  WR2: NOT EXISTS(SELF\Packaged_part.implemented_function);
  WR3: NOT ('ALTERED_PART_ARM.ALTERED_PACKAGED_PART' IN TYPEOF(SELF));
END_ENTITY;
(*

Attribute definitions:

used_package: specifies the Package_external_reference for the Minimally_defined_connector that may be used to assist in the identification of suitable mating connectors. There shall be one or more used_packages for a Minimally_defined_connector.

terminal: specifies an inverse relationship that specifies that the existence of the Minimally_defined_connector is dependent on the existence of the Shape_element that specifies the Minimally_defined_connector as its associated_definition. There shall be one or more Shape_elements for a particular Minimally_defined_connector. The Shape_elements are the terminals of the connector.

Formal propositions:

WR1: The access_mechanisms inherited from Packaged_part shall have no elements in its items.

NOTE 3   It is necessary to avoid populating access_mechanisms to avoid confusion to receivers.

WR2: The implemented_function inherited from Packaged_part shall not exist.

NOTE 4   The implemented_function is not permitted because the connector type of an instance conveys the function of an interface.

WR3: The Minimally_defined_connector shall not also be a member of Altered_packaged_part.

NOTE 5   A complex instance with Altered_packaged_part is unsupported because a communications protocol is a requirement specification, not a manufactured product

4.3.2 Protocol_physical_layer_definition   

A Protocol_physical_layer_definition is a type of Requirement_view_definition. A Protocol_physical_layer_definition is a description of the information needed to specify requirements for the lowest level interface for communication or another engineering operational protocol. The protocol specification is referenced by the documentation attribute inherited from the Product_view_definition Application Object. A Protocol_physical_layer_definition includes references to minimum information for connectors, host transmit and receive functional definitions, and host transmit and receive functional characteristics. The functional definitions should be used to identify signal names if needed, as it is common for protocols to not define connectors. If the protocol defines a connector and signal names for that connector, then the functional definition terminals are mapped to the host connector terminals using one or more Functional_usage_view_to_part_terminal_assignments. A media_connector may be a connector on an antenna. The host_connector and media_connector form a mated pair when assembled via their respective terminals. If the protocol does not define a connector or if non-standard connector implementation is chosen, members of Protocol_requirement_allocation_to_part_terminal may be populated to specify the product-specific mapping for the protocol.

NOTE    The Protocol_physical_layer_definition is provided to enable verification of product models against physical and functional requirements imposed by protocol definitions. The Protocol_physical_layer_definition is referenced by Interface_requirement to establish a requirement. The functional requirements are most often functional in nature but are not required to be by this part of ISO 10303.

EXAMPLE 1   A physical layer consisting of RS 232 compliant elements would be represented by a host functional unit, a media functional unit, a host connector, a media connector, and members of Functional_usage_view_to_part_terminal_assignment to accomplish the functional to physical mapping. If detailed functional characteristics of the media were desired, the media functional unit would reference members of Analytical_model_application.

EXAMPLE 2   A design group implementing an ARINC 429 interface for an electronics unit would populate one member of Protocol_physical_layer_definition and as many members of Protocol_requirement_allocation_to_part_terminal as needed to specify the pin mapping from the unit connector terminals (Assembly_module_terminal) to the signal names (signal_name attribute of Functional_unit_usage_view_terminal_definition) for each application of the protocol in the unit.

EXPRESS specification:

*)
ENTITY Protocol_physical_layer_definition
  SUBTYPE OF (Requirement_view_definition);
  host_connector : OPTIONAL Minimally_defined_connector;
  host_functional_definition : Functional_unit_usage_view;
  media_connector : OPTIONAL Minimally_defined_connector;
  media_functional_definition : OPTIONAL Functional_unit_usage_view;
DERIVE
  reference_document : SET[0:?] OF Document_definition := get_document_definition(SELF, 'reference document', 'DOCUMENT_DEFINITION_ARM.DOCUMENT_DEFINITION');
WHERE
  WR1: EXISTS (reference_document) AND (SIZEOF(reference_document) = 1);
  WR2: EXISTS(host_functional_definition) OR EXISTS(media_functional_definition);
END_ENTITY;
(*

Attribute definitions:

host_connector: specifies one role of the Minimally_defined_connector for the Protocol_physical_layer_definition. The value of this attribute need not be specified.

host_functional_definition: specifies one role of the Functional_unit_usage_view for the Protocol_physical_layer_definition.

media_connector: specifies one role of the Minimally_defined_connector for the Protocol_physical_layer_definition. The value of this attribute need not be specified.

media_functional_definition: specifies one role of the Functional_unit_usage_view for the Protocol_physical_layer_definition. The value of this attribute need not be specified.

reference_document: specifies the role of the Document_definition for the Protocol_physical_layer_definition. The reference_document should be provided.

Formal propositions:

WR1: The reference_document shall exist, and its size shall be one.

WR2: At least one of host_functional_definition, media_functional_definition shall exist.

4.3.3 Protocol_physical_layer_definition_with_characterization   

NOTE 1   The functional specifications are in the form of numerical simulation test setups that support capturing stimulus-response data under controlled circumstances. Each setup will include source and load functional elements along with time or frequency (or both) related data values with which to stimulate the item, and data values for time or frequency based response.

NOTE 2   The stimulus response data sets are organized according to receiver, transmitter, and media for convenience.

EXPRESS specification:

*)
ENTITY Protocol_physical_layer_definition_with_characterization
  SUBTYPE OF (Protocol_physical_layer_definition);
  host_rcv_functional_characterization : OPTIONAL SET[1:?] OF Functional_specification_definition;
  host_xmt_functional_characterization : OPTIONAL SET[1:?] OF Functional_specification_definition;
  media_functional_characterization : OPTIONAL SET[1:?] OF Functional_specification_definition;
WHERE
  WR1: EXISTS (host_rcv_functional_characterization) OR EXISTS (host_xmt_functional_characterization) OR EXISTS(media_functional_characterization);
END_ENTITY;
(*

Attribute definitions:

host_rcv_functional_characterization: specifies the Functional_specification_definition that provide a collection of stimulus response data sets for the receiver for the Protocol_physical_layer_definition_with_characterization. The value of this attribute need not be specified.

host_xmt_functional_characterization: specifies the Functional_specification_definition that provide a collection of stimulus response data sets for the transmitter for the Protocol_physical_layer_definition_with_characterization. The value of this attribute need not be specified.

media_functional_characterization: specifies the Functional_specification_definition that provide a collection of stimulus response data sets for the media for the Protocol_physical_layer_definition_with_characterization. The value of this attribute need not be specified.

Formal propositions:

WR1: At least one of host_rcv_functional_characterization, host_xmt_functional_characterization and media_functional_characterization shall exist.

© ISO 2019 — All rights reserved