Embedded System Process Guide

Process:

The various types of work that need to be performed in order to proceed with the development of embedded software has been largely divided into the following four processes (or work clusters):

(1) System Engineering Process:

This process mainly consists of the various types of work for developing the embedded system built on the basis of the software that would be embedded.

(2) Software Engineering Process:

This process mainly consists of the various types of work related to the actual software development.

(3) Safety Engineering Process:

This process consists of the various types of work that should be carried out to develop an embedded system that can be used safely and without anxiety.

(4) Support Process:

This process consists of the various types of work for providing a wide range of support that becomes necessary in the course of the development (e.g.: documentation).

Task

The various types of specific work required to execute the individual activities and achieve the predefined objectives of these activities respectively have been grouped into a lower-leveled work cluster called.“task”. For example, the activity named “Software Requirements Definition” is composed of the following two tasks:

Sub-Task

The specific portions of any given tasks that need to be performed (often step by step) to complete the individual tasks have been grouped into a work cluster of the lowest level called “sub-task”. For example, the task named “Creating the Software Requirements Specifications” is composed of the following five sub-tasks:

• Identifying the Constraints
• Clarifying the Functional Software Requirements
• Clarifying the Non-functional Software Requirements
• Prioritizing the Requirements
• Creating the Software Requirements Specifications

There are many ways of perceiving the term “embedded system”. To some, it may mean a “single equipment”. Some others may say that it is an “aggregate of multiple equipment”. There are even some that support the extended interpretation that the equipment integrated with the server is also an inclusive part of embedded system. In this guidebook, the embedded system is simply defined as a “single equipment”. At the core of each embedded system are one or more functionalities that each system is expected
to provide. each of these functionalities provided by the system is referred to as the “functional block”, and the embedded software used to make each system function is broken down hierarchically into “functional unit” and “program unit”.

Functional block
Normally, an embedded system provides multiple functionalities. A combination of a specific hardware and specific embedded software, which forms one functional block, is necessary to realize each of these functionalities.
Embedded software
Embedded software is an entity that constitutes a part of the embedded system, and is composed of a specific combination of functional units.
Functional unit
Functional unit is an entity that constitutes a part of the embedded software, and is composed of a specific combination of program units.
Program unit
Program unit is an entity of the lowest level (e.g.: compile or test unit) that constitutes a part of the functional unit.

1. System Engineering Process:

1.1 System Requirements Definition

• Creating System Requirements Definition: Understanding product plan description, understanding product specification, Analyzing and sorting Functional & nonfunctional System Requirements, clarifying system operational constraints, Prioritizing the system requirements, Create system requirements specification
• Reviewing System Requirements definitions

1.2 System Architectural Design

• Creating System Architectural design description: Confirming the design conditions, Designing the system structure, designing overall system behaviors, Designing the interface, Create System Architectural Design Description
• Reviewing the System Architectural Design Description: Reviewing the System Architectural Design Description internally, Jointly Reviewing the System Architectural Design

1.3 System Integration Testing

• Preparing for System Integration Testing: Preparation of System Integration, Preparation of System Integration Test
• Conducting System Integration Tests
• Reviewing System Integration Test Results

1.4 System Testing

• Preparing for System Testing: Creating System Test Specifications, Preparing for System Tests, Reviewing the System Test Specifications internally, Conducting the System Tests, Reviewing the System Test Results
• Reviewing the System Test Results
• Confirming the completion of System Development

2. Software Engineering Process

2.1 Software Requirements Definition

• Creating Software Requirements Specifications: Identifying the constraints, Clarify the functional software requirements, Clarify the non-functional software requirements, Prioritizing the requirements, Creating Software Requirement Specifications
• Reviewing Software Requirement Specifications

2.2 Software Architectural Design

Creating Software Architectural Design Description: Confirming the design conditions, Designing the software structure, Designing the overall software  behavior, Designing the interface, Estimating the performance/ Amount of memory used, Creating Software Architectural Design Description

2.3 Software Detailed Design

• Create functional unit detailed design description: Dividing into program units, Designing the program units, Defining the interface in detail, Estimating the amount of memory used, Creating Software Detailed Design Description
• Reviewing Software Detailed Design Description: Reviewing Software Detailed Design Description Internally, Checking consistency with hardware specifications

2.4 Implementation and Unit Testing

• Preparation for implementation and Unit Testing: Preparing for implementation, Preparing for unit tests
• Conducting Implementation and Unit Tests: Implementing the program units, Conducting the unit tests, Reviewing the Unit Test Results
• Review the implementation and Unit Test Results: Reviewing the source code, Reviewing the Unit Test Results Internally

2.5 Software Integration Testing

• Preparing for Software Integration Testing: Preparing for Software Integration, Preparing for Software Integration Tests
• Conducting Software Integration Tests: Software Integration, Conducting Software Integration Tests, Reviewing Software Integration Test Results
• Reviewing Software Integration Test Results: Reviewing Software Integration Test Results Internally

2.6 Preparing for Comprehensive Software Tests

• Preparing for Comprehensive Software Tests: Creating the comprehensive software Test Specifications, Preparing for Comprehensive Software Tests, Reviewing the comprehensive Software Test Specifications
• Conducting the Comprehensive Software Tests: Conducting the Comprehensive Software Tests, Reviewing the comprehensive Software Test Results
• Reviewing the comprehensive Software Test Results: Reviewing the comprehensive Software Test Results Internally, Confirming the completion of software development

3. Safety Engineering Process

3.1 Safety Requirements Definition

• Creating the Safety Requirements Specifications: Understanding Product Plan Description and Product Specification, Examining potential system failures, Examine the requirements to achieve required safety, Creating Safety Requirements Specifications
• Reviewing Safety Requirements Specifications: Reviewing Safety Requirements Specifications Internally

3.2 Safety Testing

Preparing for Safety Test, Conducting the safety tests, Reviewing the safety tests results, Reviewing the safety tests results internally

4. Project Management

Creating Project plan description, understanding the product execution status, controlling the project life cycle, creating project completion report.

Quality Assurance: Defining the Quality Objectives, Establishing Quality Assurance, Controlling the quality based on quality visualization.

Risk Management: Identifying and Understanding the risks, Monitoring the Risks, Determining and executing Risk Treatments, Understanding the objectives of configuration management In the course of system and software development, various problems are bound to occur and impact the efforts to achieve the quality objectives. However, many of these problems are often predictable. Therefore, there is usually a need to investigate the hidden risk factors and identify the potential risks both before and after commencing the project. And after the project has been launched, appropriate risk management must be carried to check whether or
not there are any problems arising at the given moment, and also whether the treatments for foreseeable risks are put into practice to prevent those risks from actually occurring.

Configuration Management: Recent system and software development projects are often planned to develop products in series, and tend to have multiple system and software versions developed concurrently. In such forms of development, version management plays a significant role, because appropriate management of information that specifically tells which functionalities have been implemented for which version is of vital importance. Moreover, in such cases, a database to manage all the deliverables collectively is normally prepared. Following the “check-in / check-out” procedure is a desirable method to develop a new version derived from one of the deliverables stored in this database. Derivative versions must be properly managed in order to prevent the users from making mistakes like selecting the wrong files instead of the product release version files that they were actually looking for. Especially when a defect is found and a need to search for all the related versions subject to modification arises, confusion in version tracking may cause a serious impact on the progress of the development. Therefore, the relationship between individual versions must be clearly understood. If necessary, create a chart showing which versions are co-related to help understand the associativity of the versions more easily.

Problem Resolution Management: The purpose of “Problem Resolution Management” is to appropriately process the defects that are detected
or indicated in reviews and tests conducted on interim and final deliverables created in the course of system or software development. Beside these defects, there are also various problems and issues that arise during the
execution of the development project.

Reference: Embedded System Development Process Reference Guide By Software Engineering Center, ITPA , Japan.