19.__HAMAAR_Template_-_8_Mar_16.pdf

System Name

Hardware and Memory Architectural Analysis Report

Date

Version

Contact Information

Note: This document is meant to serve as a Hardware and Memory Architectural Analysis Report (HAMAAR). The purpose of this document is to provide the following:

Overview of the system

Component break-out of the entire system

Detailed architectural-layout of the system (How each part of the system connects.)

Detailed internal data-flow analysis of the system (How/What the pieces of the system all communicate with/to each other.)

Detailed external data-flow analysis of the system (How/What the system communicates externally with/to.)

Detailed memory analysis of each component of the system (Each memory component in the system should be clearly identified along with its exact purpose in the system.)

Detailed software/firmware analysis of each component of the system (Each software/firmware piece should be clearly identified along with its exact location and purpose in the system.)

Memory verification methods (Methods for external government organization to verify system integrity)

1. Manufacturer: Name and Location

2. System Model: System name, model and part number (If system is made up of multiple components, please provide name, model and part number of each component of system.)

3. System Purpose: Brief description of intended use/purpose of the system

4. System Description: Provide detailed description of the system. Please ensure that the following is included:

4.1. System overview

4.2. Detailed breakout of all components in system with pictures: If system has multiple components, ensure that correct name of each component is identified. As an example, System X is made up of the following Line Replaceable Units (LRUs). Each of the individual LRUs purpose should be defined in this section.

4.3. Detailed architectural-layout of the system: This should include system connection points and types. This should include complete architectural diagrams which show layout of entire system, board/card/chip level architecture within each LRU listed in section 4.2:

This should include system connection points and types of connections with P/N, storage capacity and paths /direction of signals from the memory devices on each board/card/chip as identified above in a schematic format of the memory flow. These diagrams should flow from high level to lower level, with lower level showing connection points of ALL devices which CONTAIN MEMORY. (Reference Figures 1 – 5 below) Begin with high level system layout then progress to lower level architecture diagrams of each system component.

Figure 1 High Level Arch Diagram Example

Figure 2 LRU 1 High Level Arch Diagram Example

Figure 3 LRU 1 COTS Processor Card Lower Level Arch Diagram Example

Figure 4 LRU 1 Special Processor Board 1 Lower Level Arch Diagram Example

Figure 5 LRU 2 Lower Level Arch Diagram Example

4.4. Detailed internal data-flow analysis of the systems board/card/chip level architecture as defined in each LRU: This should explain how and what each piece of the system communicates. Use architecture diagrams to further explain this data flow.

4.5. Detailed external data-flow analysis of the system systems board/card/chip level architecture as defined in each LRU: This data might consist of external Interface Control

Document (ICD).

5. Detailed Memory/Software/Firmware System Analysis: This should include exact type of memory, volatility, size, P/N, version of S/W-F/W, and system purpose. Each memory device shown in lower level architecture diagrams should have the following detailed:

5.1. Capacity (32 Meg, 64 Gig, 56 K…)

5.2. Volatility (volatile, non-volatile)

5.2.1. If volatile memory: Time to clear memory after power off and residual bits/information after clearing

5.2.2. If non-volatile memory: Is the memory writable/accessible during a run-time environment, and how is this possible?

5.3. Type / P/N (EPROM, EEPROM, Flash, NVRAM, SDRAM, DPR…)

5.4. Battery back-up (if so, what type and part # of battery)

5.5. Purpose (System ID #, System boot configuration, initialization parameters…)

5.6. Accessibility (via bench loader, via Ethernet…)

5.7. Size of software/firmware expected in each memory location

5.8. Spacing (fully utilized, have available memory space for additional information to be placed…)

5.9. Memory lock-down (Is memory locked down, does possibility exist to lock it down…)

5.10. Software/Firmware which is present in each particular memory location w/ S/W-

F/W version: (Ensure that system flow explanation is present. This would include:

Operating System (OS), Board Support Package (BSP), Operational Flight Program

(OFP), Firmware or Micro-Code.

5.11. Clearing or re-formatting ability of each particular memory device (Include vendor level formatting or clearing instructions. Additionally, if an approved sanitization procedure exists, (Department of Defense or Federal) include certification documentation to support the claim.)

6. Memory Verification Methods:

6.1.1. Verification method for each particular piece of memory within each

LRU/board/card/chip, identified in the system as applicable. If unable to test explain?

(Detail how to verify the system integrity. Please state if it is NOT possible to verify a particular memory location. Verification methods may include CRC of an internal memory device, both before and after run-time. Objective is to know ALL data that is stored in

ALL memory devices.