Three Key Lessons of Semiconductor Requirements Engineering

Requirements & Requirements Management

Three Key Lessons of Semiconductor Requirements Engineering

By |

Three Key Lessons of Semiconductor Requirements Engineering

Three Key Lessons of Semiconductor Requirements Engineering

Semiconductors are ubiquitous in our modern life. The thermostat that regulates the temperature in our home overnight, a cellphone with an alarm that wakes us up, our power toothbrush, and the coffee maker that has the morning’s cup already brewed as we walk into the kitchen. Semiconductors make these conveniences and millions more per day possible, most without our awareness or intervention at all.

It’s not hard to imagine requirements for a thermostat, a cellphone alarm, a toothbrush, or a coffeemaker. What about the electronic components that control each of these devices, along with so many others that function transparently in our lives throughout our day? Whether they are the latest generation GPUs powering streaming media in datacenters, CPUs powering laptops on which we work, network chips executing communications protocols, or FPGAs warning us of vehicles in the lane adjacent to our own car, semiconductor products are essential ingredients of our daily lives.

In this blog post, Sarah Crary Gregory, a member of the Industrial Innovation Committee of the IEEE Requirements Engineering Conference, discusses three lessons learned in semiconductor requirements engineering.

Do semiconductor products have requirements?

Sarah Crary Gregory: Yes.

That’s the simple answer. Reality is more complicated.

Semiconductor products have definitional data – content that describes the functionality of the product, expectations of the quality of those functions, and constraints that the product must exist within. Whether those statements are written in Natural Language or with a different notation will depend on several factors, including the type of product under design, the level of abstraction of the data, and the norms of both the company and the structure needed to manage the data itself.

Semiconductor products have little or no utility without the system of systems of which they’re a critical constituent part. Those broader systems – a cellphone, a communications satellite, a car – have their own requirements. They may not always be directly included in the requirements for the semiconductor part itself, but they inform the structure and relationships of the definitional data – requirements as well as architecture – of that semiconductor.

Let’s take the use case of blind spot detection in an automobile. At the highest level, the user requirements cover one primary user class – “driver” – but two distinct actors: 1) the driver of a car who intends to change lanes, and 2) the driver of the car in an adjacent lane. Their goals are the same and implicit: reach their destinations safely. If both cars are equipped with blind spot sensors, both drivers may be notified by their respective vehicle of a potentially dangerous situation. The existence of that notification, its accuracy, and how that notification is delivered – audible signals, visual references, even potentially an override function in which the car itself avoids the collision – all are requirements.

Of course, users don’t walk into a car dealership showroom with a Product Requirements Document (PRD) detailing the functionality and performance expectations of the blind spot detection system for their new car. They may expect the feature, but trust that the automobile manufacturer has defined, developed, and delivered that functionality, and it will “just work.” Designers of the automobile will consider and specify many elements of what blind spot detection must do. For this feature, additional 3rd party standards from ISO or the National Highway Transportation Safety Administration in the US (along with other regulatory bodies) may govern implementation details as well.

As the design of the feature is decomposed into its constituent parts – sensors, digital signal processors, lights – the characteristics of these elements will be specified, often as requirements. How bright must a visual signal to the driver be? Where does that need to be located for easy reference without distracting from the task of driving the car? How loud must the audio signal be? Is there a requirement that it be audible over any media playing in the car at the same time? How rapidly must a signal from the sensor be conveyed to the blind spot detection system to ensure prompt notice to the driver? Again, independent safety standards might govern some elements of these features. Manufacturers’ design standards may lead to other requirements for how the signal is presented to the user, within the constraints of the standards.

Many of these details have requirements implications for the various electronics including FPGAs and CPUs that control the systems of the car. The automotive company will select semiconductor components that satisfactorily meet its requirements. Those semiconductor components themselves must demonstrate that they meet the automotive company’s requirements. Some of this demonstration is accomplished via testing, but it is also assessed through the definitional data of the semiconductor product itself – including its requirements.

RELATED: Leading Quantum Computing Company, IonQ, Selects Jama Connect to Decrease Review Cycles, Reduce Rework

What standard or template applies to semiconductor requirements?

Gregory: The short answer: There often is not one. That’s an unsatisfactory answer, of course, worthy of further exploration.

Unlike the Avionics (DO-178C/DO-254, and others), Automotive (ISO 26262, IATF 16949), Industrial Automation (IEC 61508), or Medical Devices (ISO 13485 and others) industries – among many others – the Semiconductor industry does not have one or more guiding industry standards that define the product’s data architecture. The data defining a product often reflects the mental model(s) of its authors, the company or team’s legacy practices, or the best effort made to capture information in the tool(s) available, often Word or Excel. Some companies may use sophisticated modeling for system architecture but specify some requirements with natural language requirements written in the EARS syntax to ensure readability.

In practice, this may mean that many different models exist in a semiconductor company, including the standards-defined data models above. An FPGA company may develop products that are targeted for the automotive sector. Depending on the nature of those products and how they relate to safety-critical systems, a data model based on the ISO 26262:2018 standard may be required. The same company may also deliver to Avionics or Medical Device companies and need to demonstrate requirements management consistent with those standards. Careful data architecture in the development of the Requirements structure may deliver a model that’s applicable across many standards. Each may still require different documentation output to demonstrate that the product will be able to be certified as safe to use.

So – sometimes semiconductor companies do need templates, at least for some components. Here’s an example that would apply for our Blind Spot Detection system.

Depending on the component being developed, SEooC (Safety Element out of Context) rules may apply to the supplying semiconductor company, even if their primary business is not supplying the automotive market. A formal Hazard Analysis and Risk assessment (HARA), Functional Safety Concept and Technical Safety Concept, ASIL decomposition may be required to provide compliance to ISO 26262. Jama Software provides a templated data model that facilitates reuse for this this type of development. This is especially helpful for semiconductor companies with a broad and diverse range of customers and products in their portfolio. Components that might fill a niche in a safety standard-defined market can be demonstrated to be compliant without the need to maintain separate infrastructure for their data. Other products and components at the same company can be in the same infrastructure, managed by templates suitable for their needs.

Relationship diagram if Jama Connect showing an example of a semiconductor requirements project framework.

What are requirements for a Requirements Management System (RMS) for the Semiconductor segment?

Gregory: Semiconductor Requirements Management requires both stability and flexibility.

  • Stability: In the absence of a domain-specific standard that governs data objects and their relationships, semiconductor companies often must define and govern the structure themselves. Being able to design an information architecture that both reflects the common practice in use today – even if in Excel or Word – but takes advantage of features of an RMS that add rigor and discipline to requirements reviews and traceability is the sweet spot for semiconductor companies looking to improve their requirements management game.
  • Flexibility: A robust RMS solution will enable one or more “locally-standard” data models to be created that reflect the definitional data relationships of the system under design and its various components at a particular company. That data model must be governed to ensure that it is used consistently. Changes to the data model must be addressed through disciplined change management practices.

Different levels of abstraction of data may require different management solutions. Use Cases may be modeled in a MBSE tool or captured in UML-compliant text form in Jama Connect®. Product requirements and derived component requirements, potentially through multiple levels of abstractions, trace back up to the Use Cases. Connecting EDA tools, simulation environments, work tracking systems, and validation environments ensures that the overall system meets the ISO9001:2015 expectation of a Quality Management System (QMS) that ensures that a product satisfies customer expectations.

Jama Connect is an industry-leading Requirements Management system that excels at both Stability and Flexibility. Working in collaboration with a Jama Software solution team, a customer from the semiconductor sector defines an information architecture that represents its data today, and that can evolve to take advantage of the powerful features afforded by Jama Connect. Design and governance of the information architecture rests in the hands of the company, with Jama support available to enable changes as the company’s data needs change.

The most important requirement for a requirements management system in any domain is that the users – marketing, strategic planning, architecture, engineering, among many other roles – are willing to use it! Jama Connect is easy to learn, satisfying to use, and a robust single source of truth for semiconductor product definitional data. Every semiconductor company’s products can have specific information architecture needs. Reach out to us at Jama Software today to learn more about how the flexibility and stability of Jama Connect can meet you where you are to solve your company’s semiconductor requirements management challenges.

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

Glossary of Definitions:

  • ASIL: Automotive Safety Integrity Level. ASIL is a risk classification system defined by the ISO26262 – Functional Safety for Road Vehicles standard.
  • CPU: Central Processing Unit. The CPU is the primary processor in a given computer. A single computer can contain multiple discrete CPUs, called “cores.”
  • FPGA: Field Programmable Gate Array. An FPGA is a configurable integrated circuit that can be programmed and reprogrammed repeatedly after purchase and installation.
  • GPU: Graphics Processing Unit. A GPU is an electronic circuit specifically designed to process digital images and accelerate computer graphics rendering. GPUs are critical in domains as diverse as computer gaming, autonomous driving, and AI image rendering.
  • HARA: Hazard Analysis & Risk Assessment. A HARA is a standardized method of performing a risk assessment and defining safety measures in compliance with the ISO26262 – Functional Safety for Road Vehicles standard.
  • RMS: Requirements Management System. Although requirements may be captured in many formats and many types of system, a RMS is purpose-built to manage the definitional data of a product, service, or system at multiple layers of abstraction. RMS standard features minimally include the ability to define and implement an appropriate schema for the collective data, and capabilities for baselines, version control, reviews and approvals, and disciplined change control.
  • SEooC: Safety Element out of Context. A SEooC is a software or hardware element of a system that is designed and developed according to the standards established by the ISO26262 – Functional Safety for Road Vehicles standard. However, it is developed “out of context” of any particular implementation. In our example above of the automobile blind spot detection system, the sensors and other electronic components that are integrated into that feature are likely developed as generic devices that could serve multiple purposes. Because they were developed in accordance with the standard, they are potentially suitable to use for multiple safety-critical purposes.

Sarah Crary Gregory
Latest posts by Sarah Crary Gregory (see all)