Incomplete and inconsistent requirements
cause errors in the design phase,
which become exponentially more expensive to fix over time.
Customers developing safety critical applications can
save time and money by ensuring their requirements
are valid early.
Today, you will learn, what are some common challenges
with requirements validation?
What are engineers doing today to address these challenges?
Why should you model requirements?
How to model and validate requirements
with a new requirements table and requirements toolbox
and Simulink Design Verifier.
In safety critical applications, engineers
author requirements primarily with formal logical conditions.
These logic driven requirements often
represent the majority of the system's requirements.
These typically include requirements
such as fault detection, signal selection,
also known as voting, and mode logic.
These requirements are often simple and easy to validate
individually.
The challenges emerge when you need
to analyze a set of hundreds or thousands of requirements.
The top challenges are completeness and consistency.
Completeness ensures that all required functionality
is defined.
Consistency ensures that requirements do not conflict.
So what are engineers doing today
to address these challenges?
Many organizations create a set of
intermediate text-based requirements,
which often resemble pseudocode such as this example.
Notice the use of variables in the requirement.
These variables are often analyzed by text parsing tools
to check for consistency and completeness.
This process is expensive to create and maintain.
In other words, text is not always the answer.
You should model logic-driven requirements.
Requirements modeling also called specification modeling
provides several advantages over traditional text-based
requirements.
These models are mathematically rigorous executable
through simulation, easier to author and maintain
than pseudocode text requirements,
easier to analyze as the requirement set grows,
and reusable for downstream verification activities
through techniques such as automatic test generation.
In Release 2022a, requirements toolbox
includes a new requirements table block
to allow users to model and analyze
logic-driven requirements.
Each row of the table defines a requirement.
A requirement includes a summary,
which is a text-based description of the requirement,
a precondition, an expression which
defines the conditions where the requirement is valid.
This expression is written using MATLAB code.
An optional duration, which describes
the time in seconds during which the precondition must
be satisfied.
A postcondition, and expression, which
defines the conditions that must be achieved
when the precondition is met.
You can express a variables range
using standard syntax, such as parentheses and brackets.
You can also define an optional action,
which defines what actions are performed
if the precondition is valid.
Such as calling a function or assigning a value.
Finally, there are built in temporal operators.
Let's walk through a real world example.
Requirements for a DC charging code for an electric vehicle.
Will build the requirements around a standard J-Plug.
In DC charging, the electric vehicle battery
is directly connected to the charging station.
Due to safety concerns with voltage exposure at the port,
DC charge cords are required to be locked during charging.
Based on the J1772 specification,
we can define three requirements for the system.
Requirement one, the electric vehicle
shall lock the charger in place if the electric vehicle supply
equipment is compatible.
Requirement two, the electric vehicle shall unlock the cord.
If the acknowledged terminate charging session signal
is received and the vehicle measures an input voltage
that is less than 60 volts during normal shutdown
procedures.
Requirement three, the electric vehicle shall unlock the cord
If the pilot status is not ready and the vehicle
measures an input voltage that is less than 60 volts
during an emergency shutdown.
Let's use a requirements table to define these requirements.
I have already defined the first two requirements
and have written a brief summary for the third requirement.
The postcondition column defines the expected condition
of the lock command.
Let's define the third requirement.
First, let's define the precondition using
a simple MATLAB expression.
The postcondition is that the code is unlocked.
Now that we have defined the three requirements,
let's analyze the table to ensure
completeness and consistency.
To do this, just click the Analyze button.
This will launch Simulink Design Verifier to automatically
analyze the table.
It looks like the requirements have issues with inconsistency
and incompleteness.
The report provides an example for each issue.
A requirement is inconsistent when
the block can perform different behaviors
for a single combination of input values.
In other words, there are two or more conflicting requirements.
In this case, there is an inconsistency
between the first and third requirements.
Under the condition shown, requirement one
demands the core to be locked while requirement three demands
the cord to be unlocked.
Note that the scope of requirement one
is only at the beginning of the charging.
By adding this information to the precondition of requirement
one, we can alleviate the inconsistency.
Requirements have incompleteness issues
when the block does not comprehensively specify outputs
for possible input values.
In other words, the expected functionality
has not been fully defined.
In this case, the expected functionality
for the lock command based on the inputs is incomplete.
Basically, the requirements do not
specify what the lock command should
be if the vehicle is in normal shutdown,
and the port voltage is still unsafe.
To address this, we'll need to add new requirements.
This is an iterative process.
In most cases, you will need to continue updating requirements
until there are no remaining issues with inconsistency
and incompleteness.
Here is the final result. Real systems
have physical limitations which should be accounted
for in the requirements.
We can define these using assumptions.
In this case, there are three assumptions
for the charging status.
These assumptions will be used when analyzing the table.
When you create a requirement in a requirements table,
the block automatically creates a requirement,
you can manage in the requirements editor.
You can use the requirements editor
to link requirements in the requirements table
to model elements.
And view traceability data using a traceability matrix
or traceability diagram.
This demo showed you how to model
a set of logic-driven requirements
in a requirements table, and analyze
the requirements to ensure completeness and consistency.
This will help ensure these requirements are
valid before beginning the design.
To get started, check out the example
in requirements toolbox.