Search Results

The goal behind Functional Safety is to anticipate the potential hazard scenarios (a.k.a. harm sequences) that a system may produce and address those scenarios in such a way as to mitigate or even eliminate them. A major challenge in determining hazard scenarios is trying to assess an adequate amount of scenarios, considering the large size of a hazard space. Typically assessing the entire hazard space is difficult to achieve, resulting in the possibility of overlooking some critical scenarios that can result in harm to either system operators, system by-standers, or both. In this paper we will explore a rule-based approach for concisely describing hazard scenarios, which could potentially enable us to examine the entire hazard space in a short amount of time. Our approach, called Hazard Space Analysis, combines three key activates: determining hazard scenarios, assigning a risk factor to those scenarios, and mapping those hazard scenarios directly to safety rules.

When specifying an embedded system-to-be, a key consideration is how the embedded system will interact with its operating environment. Of particular concern is the system's vulnerability to Off-Nominal Behaviors (ONB) from human interaction. ONB vulnerability can result in human operators placing the system in an undesired state through an unforeseen sequence of events. This, in turn, can have an adverse effect on the system’s quality. Reducing ONB vulnerability can be challenging because human behavior can be unpredictable and stakeholders have a natural tendency to assume the system will be used in a predictable, nominal, manner. One approach to reducing ONB vulnerability is to specify the system as "fool-proof" as possible, during the requirements phase, where access to domain experts is at its most convenient.

Requirements engineering is an important part of the software development process. There are various challenges associated with the elicitation, analysis, documentation, and validation of requirements, and these challenges can be more pronounced in embedded software systems, where a number of characteristics, unique to these systems, must be addressed. This paper will examine the unique concerns surrounding the requirements engineering of embedded software systems, including the need to elicit, specify, and validate, interrupts and exceptions, concurrency, and timing. We will then survey and examine some of the current requirements engineering research that can address these concerns. Finally, we will consider whether some of the requirements engineering concerns and practices conceived for, and utilized in the Information Technology (IT) domain, can be beneficial to the development of embedded systems.