Article Title: Overview of Requirement Descriptions for Embedded SystemsAll Authors: Chen Xiaohong, Liu Shaobin, Jin Zhi
First Institution: Shanghai Key Laboratory of High-Confidence Computing (East China Normal University)
Publication Time: 2025, 36(1): 27-46
Abstract
With the widespread application of embedded systems, their requirements are becoming increasingly complex. Requirement analysis has become a critical phase in embedded system development, and accurately modeling and describing requirements has become a primary issue. This paper systematically surveys the requirement descriptions of embedded systems and conducts a comprehensive comparative analysis to gain a deeper understanding of the core concerns of embedded system requirements. First, a systematic literature review method is employed to identify, filter, summarize, and analyze relevant literature published from January 1979 to November 2023. Through automated retrieval and snowballing processes, 150 papers closely related to the topic are selected, striving for comprehensiveness in the literature review. Secondly, the expressive capabilities of existing embedded requirement description languages are analyzed from the perspectives of requirement description focus, requirement description dimensions, and requirement analysis elements. Finally, the challenges faced by existing embedded system software requirement descriptions are summarized, and requirements for the expressive capabilities of embedded system requirement description methods are proposed in relation to embedded software intelligent synthesis tasks.
Scan to read the full textContent
1 Reference Architecture of Embedded Systems
This paper presents a reference architecture for embedded systems, as shown in Figure 1. Here, the embedded system is viewed as a complex of software and hardware with specific functions, where software acts as the controller coordinating the system devices to fulfill the design intent of the embedded system, and hardware devices mainly include various sensors, actuators, and other devices that the system can manage and schedule. The controller communicates with the external environment through system devices, which include super administrators, external software systems, natural environments, and physical environments.
Figure 1 Reference Architecture of Embedded Systems
The expectations and requirements for different components in the above reference architecture of embedded systems will yield different types of requirement descriptions. These types includesystem task intentions, system capability requirements, software capability requirements, hardware requirements, and software design constraints..
System task intentions express the goals of the system. Since embedded systems will act on the external environment, following the requirement engineering concept based on environmental modeling, system task intentions are usually reflected in responses to expected changes in the external environment.
System capability requirements describe the capabilities that the system must possess, which are specific conditions or requirements that must be met to achieve the system task intentions. Specifically, since embedded systems will interact with the external environment through system devices, their capabilities are based on the input and output relationships between the embedded system and the external environment, i.e., the input and output of system devices with the external environment.
Software capability requirements refer to the capabilities that the software needs to possess to schedule, manage, and control system devices to meet system capability requirements. They are often manifested in the input, output, and their relationships between the embedded software controller and system devices, also known as embedded software requirements, which include various functional and non-functional requirements.
Hardware requirements are constraints on embedded hardware devices, which can be divided into system device requirements and software runtime platform requirements. System device requirements mainly involve various sensors and actuators.
Software runtime platform requirements refer to the requirements for the hardware platform that supports the operation of embedded system software, such as a memory capacity of no less than 128 MB, storage space of no less than 1 GB, and a processor that must process 5 million instructions per second.
Software design constraints are obtained during the development process. The typical requirement development process is: first, through system goal analysis, study the expected changes in the external environment to derive the system’s task intentions. Then, through system capability analysis, the task intentions are specified into input-output relationships between the system and the external environment, deriving system capability requirements. Next, hardware-software partitioning is performed, and by analyzing the interactions between software and external devices and the requirements for external devices and platforms, software capability requirements and hardware capability requirements are obtained. Finally, preliminary design constraints for the software can be derived.2 Literature Review MethodThis paper aims to gain an in-depth understanding of the core concerns of embedded system requirements and the capabilities of requirement description languages, for which two research questions are designed.RQ1: What types of requirements are involved in common descriptions of embedded systems?RQ2: How capable are existing embedded system requirement description languages?This paper is based on requirement engineering, embedded systems, embedded software, requirement descriptions, process control systems, real-time systems, and other related Chinese and English keywords, and retrieves 3442 papers from domestic and international literature databases. From the 3442 papers, 150 papers are selected as the research set. Figure 2 shows the distribution of the collected literature according to different stages of software development. Figure 3 shows the distribution of literature according to application fields.
Figure 2 Statistics of Different Stages Involved
Figure 3 Statistics of Major Application Fields
3 Types of Requirement Descriptions for Embedded Systems
System task intentions describe the high-level goals that the system aims to achieve.
System capability requirements are descriptions of the system’s functions. Since embedded systems include both hardware and software, the software must perceive information from the external environment through devices such as sensors and exert control over the external environment through devices such as actuators. Therefore, system capability requirements are often manifested in the interactions between system devices and the external environment or the relationships between inputs and outputs from the external environment.
Software capability requirements include the functional and non-functional requirements of the software. Software functional requirements describe the relationships between the inputs and outputs of the software. Embedded software interacts with the external environment through sensors and actuators, and its inputs and outputs are obtained through these devices.Non-functional requirements mainly include time-related requirements, reliability, robustness, personal safety, information security, etc. Time-related requirements include timing requirements, real-time requirements, time constraints, performance, etc. According to the strictness of time requirements, time-related requirements can be divided into three categories. The first category is requirements for time sequences, the second category is quantification requirements for time periods and moments, and the third category is requirements for real-time performance.Personal safety requirements refer to measures to prevent the system from harming personal safety or property safety, generally expressed in terms of what the system is not allowed to do, describing specific statements about the existence of safety elements in the system, combined with minimum or maximum requirement thresholds of some quality metrics. Other common non-functional requirements includereliability and robustness. Reliability refers to the ability or probability of the system to complete specific functions. Robustness usually refers to the ability of the system to continue operating normally in the face of illegal or erroneous inputs and unexpected environmental changes. Embedded systems typically need to provide response strategies for abnormal events (such as resource failures, incorrect inputs, etc.) to ensure stable operation.Due to different requirements for peripherals and software runtime platforms, hardware requirements are further divided into requirements for peripherals and constraints on software runtime platforms. Peripheral requirements should provide requirements for the characteristics of peripherals, often including the functions of peripherals, user interactions, hardware characteristics (temperature range, humidity range, battery), action buttons, accuracy, memory specifications, response times, etc.
Constraints on the software runtime platform are the requirements for the processor, memory, and data storage space during functional design. They are all limited resources in embedded systems, so they must be described.
Software design constraints generally include interface requirements for hardware devices, software structure, programming language, development standards, confidentiality requirements, maintainability, usability, and other requirements. Interface requirements detail the requirements for each function at the interface level, which is often used to describe the inputs and outputs of hardware interfaces. Generally, interface requirements will also include properties such as accuracy, range, and timing requirements. Here, accuracy refers to the degree of accuracy of the system’s output data, which describes the acceptable error between the output data value and the ideal value.
4 Existing Embedded System Requirement Description Languages
This paper summarizes 20 representative requirement description languages, as shown in Table 1. These languages only cover three types of requirement descriptions, namely system capability requirements, software capability requirements, and software design constraints. Among them, system capability requirements are the highest level of description. Most work focuses on the description of software capability requirements. In contrast, descriptions involving software design constraints are relatively few.Table 2 Requirement Description Languages for Embedded Systems
Descriptive focus is the perspective from which the language views the world, closely related to how the language perceives its own system’s role. Different languages have different descriptive focuses. Some languages view their own system as a reactive system, responding to events, signals, or stimuli from the external environment, thus their focus is on the events, signals, or stimuli emitted by the external environment. From the current descriptive focus, merely focusing on changes in the state of the system itself or viewing the system solely as a responder to external stimuli will make it difficult to address the issues arising from the increasing scale of embedded systems. As the number of devices increases, external stimulus events and system state data will also increase, making it challenging for users to understand and accurately express their requirements.
Due to different descriptive focuses, the descriptive dimensions of languages will also differ. The main dimensions of software requirement descriptions include behavior and data. Most languages focus more on describing behavior, primarily concerned with the flow of action behavior, describing responses to signals, events, and event conditions. These languages often use finite state machines, state transition diagrams, predicate logic, etc., for description. Some methods adopt hierarchical concurrent state machines (pattern transition diagrams) to describe complex behaviors. There are also a few languages that focus more on data transformation. Some works focus on both behavior and data, having both pattern diagrams and computational tasks. For complex embedded systems, both behavior and data have complexity, so in their software requirement descriptions, it is necessary to organically combine models of these two dimensions.
Currently, the non-functional requirements involved in software requirement description languages mainly include time-related requirements (timing, real-time, delay, performance, time constraints, etc.), accuracy, exception handling, and resource constraints. For exception handling in robustness, some languages categorize all exceptional events and system responses into three types: resource (device) failures, erroneous input data, and erroneous internal data. From the perspective of non-functional requirements, software capability requirement descriptions include functional requirements. In their existing non-functional requirement descriptions, only some requirements that can be expressed based on functionality, such as time, reliability, exception handling, and accuracy, are included. Other types of requirements that cannot be directly expressed based on functionality, such as personal safety, are not addressed.5 Analysis of Development Trends in Requirement Descriptions for Embedded Systems
① Challenges in Requirement Descriptions for Complex Embedded Systems
First, complex embedded requirement descriptions should not only involve software capability requirements but should describe all types of requirements related to embedded systems, namely task intentions, system requirements, peripheral requirements, runtime platform constraints, and software design constraints. Additionally, embedded software needs to operate on specific platforms according to specific strategies, and its resources, performance, etc., must be constrained. Software design constraints may also exist.Secondly, it is necessary to define the descriptive dimensions at each requirement level. In complex embedded systems, there are complex control and computation processes, involving both behavior and data dimensions. However, the dimensions may vary completely at different requirement levels.Thirdly, it is necessary to define a systematic software requirement specification method, to establish traceability relationships between different levels from task intentions to software requirements (including functional and non-functional requirements), to cope with the increasing complexity of embedded system requirement changes. Fourthly, it is necessary to provide more efficient requirement analysis methods for requirement decomposition and refinement mechanisms. This interweaving of devices makes the original partitioned requirement decomposition (non-interwoven) no longer applicable, as they do not consider the characteristics of the devices in the decomposition, which may lead to inconsistencies in requirements after decomposition. Additionally, with the increase in embedded devices and the complexity of embedded systems, manual requirement analysis will become a bottleneck in development, necessitating automated requirement analysis methods to improve efficiency.In summary, complex embedded systems require the design of new requirement description languages. In the design, it is necessary to extract the main components of the embedded software language based on the characteristics of embedded software, according to the requirement analysis at various dimensions and levels, and define the logic of the language to support the expression of embedded software requirements. This is a task that spans the entire requirement phase of embedded software, requiring comprehensive reference and expansion of existing requirement engineering methods, combined with effective requirement extraction, modeling, analysis, simulation, and verification technologies, to propose language structures and define structured embedded system requirement description languages with sufficient expressive capabilities.② Requirements Brought by Intelligent Synthesis of Embedded SoftwareIntelligent synthesis of software refers to the automatic synthesis of software that meets user intentions based on traditional software synthesis techniques, using machine learning and other artificial intelligence foundations, utilizing existing code knowledge. The software requirement specification that embodies user intentions serves as the basis for intelligent synthesis of software. The intelligent synthesis of embedded system software will also become a future research hotspot, bringing new requirements for the description languages of embedded system software requirement specifications.First, from the perspective of descriptive dimensions, it needs to express various dimensions of requirement specifications, including behavior, data, constraints, etc. Moreover, it also needs to include constraints on performance, efficiency, safety, reliability, etc., in order to synthesize software that meets device scheduling requirements.Secondly, from the perspective of descriptive granularity, software requirements should ideally be decomposed to a relatively small granularity, also known as atomic requirements. This granularity should ideally maintain the same descriptive granularity as the functions of software assets or be at a smaller granularity. Refinement techniques are still needed to improve requirements from high-level abstract descriptions to lower-level specific descriptions. In addition, due to the high complexity of current embedded systems, requirement decomposition or decoupling is essential.Thirdly, from the perspective of descriptive schemes, a complete project requirement specification should also clarify the dependency relationships between atomic requirements, in order to synthesize complete project code. These control dependencies and data dependencies may manifest as sequential or concurrent relationships between atomic requirements, affecting subsequent synthesis.
Finally, from the perspective of descriptive forms, software requirement description languages aimed at intelligent synthesis must be machine-understandable, to facilitate subsequent code synthesis. Ideally, they should be formally expressed, with strict syntax and precise semantics. Their software requirement specifications should be able to automatically convert into simulation models or verification models, allowing for requirement simulation, confirmation, and verification before software synthesis, and automatically generating test cases for the final synthesized software, conducting software testing after synthesis. Through multiple simulations, verifications, and tests, the quality of the synthesized code can be ensured.
6 Conclusion
This paper conducts a systematic literature review on the theme of requirement descriptions for embedded systems, providing an overview of the current status of requirement description types for embedded systems, while comprehensively comparing the capabilities of existing embedded system requirement description languages, summarizing the challenges faced in requirement descriptions for complex embedded systems, predicting future trends, and discussing the capability requirements for requirement description languages of embedded systems in relation to software intelligent synthesis tasks.
Currently, most requirement description languages only describe software capability requirements, without addressing various possible other types of requirements, such as system task intentions and system capability requirements. For future intelligent synthesis of embedded software, new requirement description languages should describe various types of requirements starting from task intentions, establish their traceability relationships, analyze the control requirement interweaving issues brought by device sharing, and through decoupling, present requirement descriptions at a suitable granularity for subsequent software asset-based code synthesis.
Author/IntroductionAUTHORAUTHOR
Chen Xiaohong, PhD, Associate Professor, CCF Professional Member, main research areas include requirement engineering, formal methods, safety-critical systems..
Liu Shaobin, Master’s student, main research area is requirement engineering..
Jin Zhi, PhD, Professor, Doctoral Supervisor, CCF Fellow, main research areas include requirement engineering, knowledge engineering..