Aerospace Systems Engineer

Interfaces

ICD Management

ICD management
    The initial step in managing the System’s Interfaces is to identify the System’s architecture. Initially this may be a “notional” architecture which will evolve as the system definition process progresses. Although the system is hierarchically organized it is generally advantageous to identify the architecture to the appropriate level (Depth) to identify meaningful “elements”. Significant elements may be defined by location, discrete functionality or contractual abstraction. Some element are internal to, and a part of, the system some are external.
    Pasted Graphic
    0‑1 – System Context Diagram
      System Interfaces exist to fulfill the needs of the behavior of the system. Use Case elaboration is performed to derive the necessary behavior of the system in fulfilling the essential Use Cases. The systems’s essential Use Cases are typically the key requirements of the system, and typically fall within a structure of “universal” Use Cases: Install, Initialize, Operate (i.e., Mission, Maintenance), Contingency, and Disposal.
      Scenario Sequence Diagrams are both a “brainstorming” tool and a documentation product which identifies and documents the exchanges between system elements (Actors) and also the functions of the actors in the execution of a specific Use Case. The elaboration of a Use Case is performed by a team composed of representatives of the elements of the architecture. As the team “brainstorms” the execution of the Use Case exchanges between actors are defined and the required functions of the Actors are identified. Typical exchanges are data and control/response traffic. The goal is to identify the presence of necessary interfaces.
      Pasted Graphic 1
      0‑1 – Scenario Sequence Diagram
      Identified interfaces may be: Internal, Internal -External or External - External. Internal interfaces are interfaces between elements within the defined system. Internal-External Interfaces are between a system element and an external element. External – External interfaces are interactions external to the system but whose behavior (products of timing) are essential to the achievement of the Use Case.
        Achieving successful functionality requires that both sides of the interface have the same understanding of the interface. Interface Control Documents (ICD) define the interface between two systems. There should be only one interface document between interfacing entities. ICDs define the required behavior and attributes of the interface. These are generally most efficiently captured using the DoD three layer model; Physical, Transport, Application, but the ISO 7 Layer Model is also an alternative.
        ICDs are design documents which must be adhered to, to assure proper behavior of the system. ICDs provide design information to the designers implementing the system functionality. 1.  Where there are no options there is no design latitude and no ambiguity (i.e., the physical envelop of a device) 2.  Where design latitude provides implementation options the ICD documents the design agreements (i.e., device B configured as 1553 RT 5). 3.  Some systems may have utilization options (i.e.. Control directive 123 or control directive ABC will turn on the device. Typically there will be factors to consider in the choice of these control directives. ) 
          Where an established interface exists and is documented by an ICD (or similar document), the engineering effort is typically to assure the interface is understood and allocated appropriately.
          In the case of a new interface the engineering effort may be more extensive.
          Interface characterization is a multi-step process beginning with the identification of the presence of the interface and continuing with the detailing of the attributes of each exchange covered by the ICD. This is part of the design process which may involve a myriad of design considerations and decisions. External interfaces require the participation of cognizant personnel from the external element. It is the ICD’s
          owners responsibility to document the design agreements in the ICD.
            The ICD approval process is tasked with the validation of the correctness of the data in the ICD. Peer Reviews by Subject Matter Expert and Systems Engineering provide the first level of assurance of the correctness of the data. External interfaces typically require Customer and Sponsor participation and often User participation.
            Approval by the relevant approving authority results in placing the approved ICD under configuration control helping to further control the risk associated with interfaces.

              ICDs are invoked from specifications when stipulating exchanges between elements. The practice of specifying an interface between two elements with a global reference to an ICD (i.e., element “Y” shall interface with element “Z” IAW ICD 123) is not useful and should be avoided. To be useful a requirement should invoke the appropriate ICD in the requirement specifying a specific exchange (i.e., Upon detection of “xyz”, element “x” shall provide element “y” time of event IAW ICD “123”.) This provides specificity by identifying a specific exchange rather than all possible exchanges addressed by the ICD. The “receiving” element spec should also have an equivalent requirement specifying its requirement to accept the data. (i.e., Upon receipt of time of event, formatted IAW ICD “123”, element “y” shall process time of event. Where the receiving element is an external actor, it is appropriate to identify “wills” in the appropriate system specification. “Wills” denote expectation of behavior compliance from elements outside the control of the system. Adherence with the will is a contractual obligation of the approving authority upon approval of the specification.
              The practice of “bookending” an exchange in both “sending” and “receiving” specifications helps to insure the system design of each element adheres to the ICD. “bookending” also provides the ability to manage the risk associated with system integration by facilitating verification of ICD compliance prior to the integration of the two elements. “bookending” also facilitates management of ICD compliance by providing a mechanism to audit each ICD attribute against the requirements invoking the interface.

                ICD attributes are validated in an incremental process which insures compliance and mitigates integration risk. The initial efforts were executed during ICD development, Data validation and Approval.
                  An audit of the requirements specifications can be used to provide assurance that the interfacing entities are both referencing the same interface document for the same functions.  Auditing the respective specifications assures that they each reference the appropriate specific section of the correct ICD. This is often what is meant by "verifying" the ICD. It is a method of confirming that the interface is correctly referenced. It is NOT verification in the sense that we verify requirements.
                    Requirement verification of system elements provides an opportunity to verify ICD compliance prior to the integration of elements. Component acceptance testing provides an opportunity to confirm that the expected interface behavior agrees with the documented behavior. This also provides risk reduction prior to assembly.