5 Part 5: V-Modell Reference Work Products

5.3 Products

5.3.10 System Design

5.3.10.4 Hardware Architecture

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

Activity: Preparing Hardware Architecture

Participating: Hardware Developer, System Architect, System Integrator

Purpose

Based on the functional and non-functional requirements posed on a »Hardware Unit, the »Hardware Architect is tasked with designing a suitable »Hardware Architecture. The Product Hardware Architecture will be used as design guide and for documenting the design decisions.

As in the system architecture development, significant architectural principles will be specified, and possible design alternatives will be examined. In accordance with the selected design alternative, the hardware unit will be decomposed into »Hardware Component, »Hardware Modules and External Hardware Modules. Relations and interfaces between the elements and to the environment will be identified and summarized. A »Data and Signal Catalog of the signals exchanged at the interfaces will be prepared. The suitability of the selected architecture for the system to be developed will be assessed. Open questions may be answered, e.g., within the scope of a prototype development.

The result of the architectural design will be documented in a set of drawings for the hardware unit, which includes all documents required for production, e.g., outline of structure, drawings, assembly instructions, list of parts, circuit and connection diagrams, layout and delivery instructions.

The hardware architecture design may lead to changes in the system architecture. Depending on the specifications in the Project Manual, the »System Architect will examine the change and integrate it immediately, if required. In individual cases, an explicit change request may be necessary.

The main responsibility for the design of the hardware architecture will be vested in the Hardware Architect who will be supported by the »Hardware Developer and various specialists for individual subjects, e.g., logistics, safety and security, and ergonomics.

The hardware architecture is the central document for the preparation of additional products. It specifies all hardware components and hardware modules of the hardware unit. The individual elements and their specifications will be devleoped in accordance with these architectural requirements.

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)

Generates

Evaluation Report Usability, Evaluation Specification Usability, Hardware Component, Hardware Specification, Evaluation Report System Element, Evaluation Procedure System Element, Evaluation Specification System Element, Data Protection Concept, Information Security Concept, Safety and Security Analysis (see product dependency 4.6)

Evaluation Report Usability, Evaluation Specification Usability, Market Survey for Off-the-Shelf Products, External Hardware Module, External Hardware Module Specification, Make-or-Buy Decision, Evaluation Report System Element, Evaluation Procedure System Element, Evaluation Specification System Element, Data Protection Concept, Information Security Concept, Safety and Security Analysis (see product dependency 4.7)

Evaluation Report Usability, Evaluation Specification Usability, Hardware Module, Hardware Specification, Evaluation Report System Element, Evaluation Procedure System Element, Evaluation Specification System Element, Data Protection Concept, Information Security Concept, Safety and Security Analysis (see product dependency 4.8)

5.3.10.4.1 Architectural Principles and Design Alternatives

The description of the Subject Architectural Principles and Design Alternatives is similar to the Subject Architectural Principles and Design Alternatives of the system architecture. The architectural principles at hardware level include, e.g., specifications for standards and guidelines which must be observed. Design alternatives at hardware level describe various possibilities for the »Hardware Unit Decomposition into »Hardware Components and »Hardware Modules.

5.3.10.4.2 Hardware Unit Decomposition

The decomposition specifies the static structure of the »Hardware Unit. The static structure describes the dissection of the hardware unit into »Hardware Components and »Hardware Modules. The design result will be documented as graph depicting the hardware elements to be realized and their interrelations. All hardware components and hardware process modules will be listed with their identificators and a long name.

The decomposition is based on the requirements posed in the »Hardware Specification for the hardware unit or a higher system element. The framework conditions will be specified by the architectural principles defined in the »Hardware Architecture and the design decisions.

The results of the final decomposition step are the production data, e.g., drawings, circuit diagrams, lists of parts and connection diagrams. This includes a detailed description of programmable logic with function, call, parameter list, transmission device and resources employed.

5.3.10.4.3 Interface Overview

The summary of interfaces of the »Hardware Architecture provides a survey of the interfaces of the »Hardware Unit and the interfaces of the corresponding elements. For the summary of interfaces, only the communication at one level will be described :

At the level of the hardware unit, the interfaces to other units and to the environment will be described.
At the level ot the »Hardware Components, the interfaces between the component within the unit will be described.
At the level of the »Hardware Modules, the interfaces between the process modules within the component will be described.

Interfaces to the environment may exist between a hardware element and the user, logistic systems or various »Enabling Systems. The interfaces are described in detail in the specification of the respective hardware element.

5.3.10.4.4 Data and Signal Catalog

The Data and Signal Catalog of the »Hardware Architecture describes all signals and variables exchanged at the interfaces of and within the »Hardware Unit, including designator, data type, data format, function and allocation of values.

5.3.10.4.5 Design Evaluation

If an architectural design for the »Hardware Unit has been selected and developed down to unit level, it must be ensured that the selected design implements the requirements in a suitable manner. The design security of the »Hardware Architecture specifies the analysis and assessment methods to be employed for the selected design. Frequently used procedures include, but are not limited to, the following:

Reliability analyses for operation and storage based on prespecified standards
Tolerance analyses, taking into account production tolerances
Vibration and thermal analyses
Board level simulation for ensuring the integrity of the signal
Simulation and assessment of the emitted and received electromagnetic waves
Analysis of the fulfillment of the confidentiality requirements
Rapid prototyping of critical portions of programmable logic in order to ensure the feasibility for a prespecified number of gates and tractates.

Execution and results of the verification will be documented. They may lead to a re-evaluation of the design decisions and a review of the architecture.

5.3.10.4.6 Hardware Elements to be Specified

The preparation of a specification for a hardware element is expensive and not always required. In order to adapt the specification effort to the requirements of individual projects, the »Hardware Architect can - based on the specifications in the Project Manual and the requirements - determine which hardware elements need a »Hardware Specification.

Critiera for the necessity of a specification may include the following: criticality of the hardware elment, complexity of the requirements posed on the hardware element, test requirements specified in the »Hardware Implementation, Integration and Evaluation Concept. In any case, a hardware specification shall be prepared for hardware elements to be tested, since this specification will be the basis for the »Evaluation Specification System Element. If hardware elements are classified as not to be specified, a rationale shall be included.