5 Part 5: V-Modell Reference Work Products

5.3 Products

5.3.9 System Specifications

5.3.9.4 Hardware Specification

Responsible: Hardware Architect (when using process module Hardware Development)

Activity: Preparing Hardware Specification

Participating: Hardware Developer, Logistics Developer, Ergonomics Manager, Safety Manager

Purpose

The »Hardware Specification describes all functional and non-functional requirements posed on a hardware element (hardware unit, »Hardware Components or hardware process module). In order to prepare the Hardware Specification, the requirements will be derived from the specifications of higher system elements or hardware elements. The specification provides standards and tools for designing and decomposing the »Hardware Architecture. If changes are required in the course of the development of the hardware element, the Hardware Specification shall be adapted at first. The »Evaluation Specification System Element defines the evaluation cases required for demonstrating the requirements of interfaces and specifications.

The Hardware Specification mainly describes the requirements posed on the hardware element and specifies the connected interfaces. In addition, requirements and interfaces will be refined and allocated to lower hardware elements.

The requirements tracing ensures that all requirements posed on the respective elements will be taken into account when the next hierarchy level will be refined. The Hardware Specification will be prepared together with the architecture design of the »Hardware Units. The »Hardware Architect is responsible for the preparation of these products, thus ensuring the consistency between specification and architecture.

Requirements of the Hardware Specification may influence the Logistic Support Specification, just as logistic requirements may influence the Hardware Specification.

Is generated by

System Implementation, Integration and Evaluation Concept, System Architecture (see product dependency 4.4)

Enabling System Implementation, Integration, and Evaluation Concept, Enabling System Architecture (see product dependency 4.5)

Hardware Architecture, Hardware Implementation, Integration and Evaluation Concept (see product dependency 4.6)

Hardware Architecture, Hardware Implementation, Integration and Evaluation Concept (see product dependency 4.8)

Depends on

Man-Machine Interface (Style Guide), Software Specification, System Specification (see product dependency 5.7)

External Hardware Module Specification, Logistic Support Specification, External Software Module Specification, Software Specification, External Unit Specification, System Specification (see product dependency 5.23)

5.3.9.4.1 Hardware Element Overview

The »Hardware Element Overview provides a brief survey of the hardware element to be realized. It outlines tasks and objectives of the hardware element, e.g., by means of a block diagram with explanatory notes. For a better understanding, the role of the element within the system, a »Enabling System or a »Hardware Unit will be described.

5.3.9.4.2 Interface Specification

An interface represents the boundary between a hardware element and its environment. It describes the data exchanged at the system boundary and their logic dependencies. Thus, the interface defines the services to be provided by the hardware element. One hardware element can support several interfaces.

The interface description collects all functional requirements posed on the hardware element, specifies all interfaces and presents them in their environment. Together with the non-functional requirements, the interface description defines the information required for developing the hardware element. The interface description describes the interfaces to other hardware elements and the interfaces to the environment, e.g. the man-machine interface or interfaces to »Enabling Systems.

The description of the functional interface is subdivided into the description of the static elements and the description of the dynamic behavior. The static behavior specifies the structure of the interface, through which the functionalities of the hardware element can be used. The dynamic behavior determines the sequence of use and the logic dependencies of the transmitted data and signals.

Static elements of a hardware interface include, e.g., information on electrical performance parameters (power, voltage, current, frequency, polarity), information on the mechanical design (type of connector, connector assignment, type of cable), or information on the technical design (function call and parameter list, transmission device, layout of user interface). The description of the dynamic behavior includes, e.g., the determination of communication protocols and their specification, the description of synchronization mechanisms and references for the use and operation of the interface. The description of functional sequences and data flows in normal, borderline and exceptional cases is also part of the dynamic behavior. Frequent interfaces of hardware elements include the following:

External communication interfaces for operations
Test and diagnosis interfaces (e.g., JTAG, switches, LED's)
Electrical, mechanical, hydraulic or pneumatic interfaces

Ideally, the description of the communication interfaces will be based on the layers of the OSI reference model.

The interface description is based on the summary of interfaces in the architecture and on the interface realizations of the »System Specifications of higher system elements. The interface description should consider if a re-use of already existing system elements is possible. In addtion, it should be ensured that the interface is stable, thus allowing a long use of the hardware element.

5.3.9.4.3 Non-Functional Requirements

In addition to the functional requirements, a hardware element must fulfill several non-functional requirements. Non-functional requirements are particularly important for hardware elements. They include at least the following requirements:

Computational capability as referred to computer architecture,
memory requirements (VM, NVM),
reliability (operation and storage, e.g. avoidance of metastability of programmable logic or data retention time in case of PROMS),
safety and security,
»Logistic Requirements (reliability, availability, maintainability, replaceability, repairability, usability, operability, disposal),
efficiency (power consumption, voltages, power supply units),
EMC (electromagnetic compatibility),
CE, »VDE,
environmental conditions,
legal requirements (safety and security, hazardous substances, etc.)
technologies to be used,
specifications for component selection,
materials, screening, marking, interfaces, heat management,
confidentiality and security (e.g., no user interface, encryption for ensuring the confidentiality of fixedly coded secret system parameters).

The non-functional requirements will be described in detail and specified by the actually required values. The non-functional requirements relevant for the hardware element will be derived from the specifications of higher system elements or hardware elements.

5.3.9.4.4 Interface Realization

The interface realization refines the functional requirements of the interface description. Requirements and interfaces will be concretized, refined and allocated to the hardware elements of the lower hierarchy levels.

The interface realization is based on the »Hardware Architecture of the higher »Hardware Unit. »Hardware Components and »Hardware Modules of the different hierarchy levels will be identified within the scope of the decomposition process.

5.3.9.4.5 Refinement of Non-Functional Requirements

Non-functional requirements are refined in parallel to functional requirements during the interface realization. The non-functional requirements will be concretized, refined and allocated to the hardware elements of the lower hierarchy level. For example, a testability requirement may be reflected in a a JTAG test interface and the definition of a precise requirement posed on the boundary scan test coverage. The refined requirements remain in existence as autonomous requirements or will be integrated into the interface realization.

5.3.9.4.6 Requirements Tracing

The requirements tracing summarizes the allocation of functional and non-functional requirements posed on the hardware element to the refined requirements and lower hardware elements. It is based on the results of the interface realization and the refinement of non-functional requirements. The bi-directional trackability (i.e. from higher to lower hardware elements and vice versa) must be ensured. The data may be presented, e.g., in form of a matrix.