Let's start the path for the validation of our battery management
system. What is the first step to consider more? Well, we know from industry
surveys that poor requirements management is the most common reason for embedded
project failure. This includes missing, incomplete, or inconsistent requirements
that don't capture the intended purpose of the project. For this reason, our
journey starts with a requirements management and, more specifically, how to
manage environments in our design environment: Simulink. Requirements
typically come from Word, Excel, or most actual environments in requirements
management tools like DOORS for example. To implement these
informal ideas into Model-Based Design is challenging when data is viewed and
managed in separate tools. For example it is difficult to establish traceability
between requirements and design. To work with requirements directly in Simulink,
there is an import operation for Word, Excel, DOORS, and support for the standard
requirements interchange format ReqIF that is supported by most requirements
management tools. if requirements change at the source
then an update operation synchronizes changes. The default is to treat external
requirements as a read-only but if you want as a Simulink user you can then edit
the requirements or add more details such as custom attributes for example.
And then export. Additionally you can also create requirements where Simulink
is the source of the requirements. Finally as I mentioned before, we can
export our requirements by ReqIF. Both the external requirements we
modified in Simulink and the requirements we wrote directly in Simulink.
Let's suppose we have an external document for the highest level
requirements. For example, a Word file. Let's say the document described in the
software architecture of our BMS. The document could contain the interfaces
of the BMS control unit with the description of inputs and outputs
enclosed in tables, the description of the software architecture with all the
software modules that Francesco described before, and for each software
model, again the description of interfaces with specific information
such as units of measurement, minimum and maximum of each signal, etc., etc. As you
can see, the document could also contain images. Let's see how to import this Word
document into Simulink.
Let's go to the apps, and here in the tool bar you can see a list of all the
apps available to you. In particular you can go down here in the model
verification validation and test, and you can select the requirements manager. When
we open the requirements manager, which is now on top or a tool strip, we can
select requirements editor. From here from the requirements editor we can
import in our requirements. So the first thing, let's import the requirements
written in Word. So we can select browse, we select document, and then we can
import. We click on open and then we can specify if we want a rich text or a
plain text. So in this case, we select rich text. We give a name to this
requirement set, and then we allow updates from the external source, and
then we click on import. This will take a few seconds, it really depends on how
many requirements you have and how big the document is. And after a little bit,
you have all the requirements imported in Simulink. So on the right you can see
exactly all the requirements that we have imported. We can expand them all to
see how many we have, and then we can take a look and see what they are. So
once again we expand all the requirements and we see that we have the
list of all the requirements written in the Word document. So we can also jump to
the location to the source by clicking show document. And here we can see
that we jump exactly to the right location. So now let's assume that at
some point you modify requirements, so for example, you change
something. In this case for the sake of showing this, we just added something. So we
save the document, and of course this means that the source of the requirement
has changed. So Simulink is able to detect this. Indeed if we go on top here
we can see that now we have a little icon here that tells us that the source
of the requirements has changed. So we can actually update requirements in
Simulink and all we need to do is to click on update, select the source of the
requirements, and what this will do is it will update requirements in Simulink
based on the source.
Now you can see that we have the requirement that was modified. Okay so
you can not only import requirements in Simulink you can even author your
requirements directly in Simulink. So let's create a requirement set. Let's give it a
name. And all you need to do to alter your requirements is just to add them.
And you can even add any desired hierarchy that you want, so for instance
here you have one, two, three. But then you can also go on a deeper level and you
can keep doing this. So you know of course this will take a bit of time to
author all the requirements but all you need to do is to have a summary here so
you can write anything you want and then you can also have a description of what
the requirement should be. I have now implemented my own low-level
requirements in Simulink, and usually what you want to do now you want to
create a bi-directional linking between the low level requirements in Simulink
and the high level requirements in Word. So first thing you select a low level
requirement. You right click and then you select for linking. At this point, you go
back to a high level requirement you right click again, and then you create a
link. So after doing this on the bottom right you can see that we have created a
double linking between the low level requirements in Simulink and the high
level requirements imported from Word.
Now let's go one step further. For the moment we're seeing how we can manage our
requirements in Simulink imported from outside or written inside Simulink in the
requirements setup window. But how it is possible to see these requirements
together with our design and created in Simulink in just one integrated view? The
answer is the requirements perspective. Let's go directly into Simulink to see
how we can activate it. This was the requirement editor meant to see and work
with requirements conveniently. But if we go back to the Simulink design canvas, we
have the ability to enable two windows: the requirement browser and the property
inspector to see the Simulink designer and requirements together. If
you select a requirement in the environment browser, you'll see all
its properties on the right. In the pocket inspector. These two windows
together are the requirements perspective. If you close these windows
you can also reopen them just by clicking in the badge in the lower right
corner and selecting the environment perspective. And we can see not only the
high level requirements but by going inside the software architecture we can
open and navigate the set of requirements we brought directly in Simulink
visualizing analyzing them in the same way. A great help that make us
ready to implement without getting lost maintaining consistency between the
design and the requirements. Now what is the next step?
well obviously the creation of traceability between requirements and
design - bi-directional links. Let's see how easy it is to manage it in
this integrated environment. We will now use a similar model where I have already
created some links between the requirements and the design. If a link
already exists by selecting the requirement we can see the block to
which it is linked highlighted in pink, and on the right we can see the
link. Once the link has been created, an icon will appear on the top right corner
of the Simulink block. If a requirement has not yet been linked, as in this case,
the creation of the link is very easy to do. Simply with a drag and drop you can
see the link just created by seeing the icon on the block and on the lower
right window. Let's show the input and output tables. In some cases it would be
very convenient to have them on the Simulink design canvas. Closing the window
on the right. Well this is possible. We can show or hide any requirements we
have linked to the design directly on the Simulink canvas in this way. But also
also for example seeing the high level requirements that describe the
state machine. Let us now jump into the into the logic of the state machine.
Here - we have many links already created, and to better visualize the
design parts linked to the requirements you can use the highlight functionality
in the tool strip. Another example of how it can be useful to have design and
requirements together is to check the properties of an input by
showing requirements in this way and selecting a Simulink block it is easy
to check on the property inspector that its properties are consistent with the
requirement. By better analyzing the state machine you can see how the
requirements can be linked even to the states that are highlighted in
violet and the mechanism is always the same. Again if we don't have a link we
can create it with a drag and drop, and see - the links to the highlightings and
the window on the bottom right corner. If you want to go into even more details
run the limits and even a single transition or an individual sub state
can be linked to our environment.
Summing up, this allows us to map every single requirement to states and
transitions in Stateflow or Simulink blocks. Even to data that are present in
inside the Simulink data dictionary, obtaining a perfect requirements
design in a very fast way. There are many other advantages that we can obtain from
a traceability created with the methods seen before. For example it may be
interesting for project managers to view the status of the requirements
implementation. That's why we have included in the ability to view it
directly in Simulink. So if we do a good job link in the requirements to the
design, or justifying the non implementation in some cases, we will
have a clear view of the progress. Let's see how you can enable this view.
Just right clicking in the requirement browser, we can add the column and for
each paragraph see the progress of the implementation. For example, the
paragraphs concerning input and output interfaces have all been implemented. This
means that we have linked them to the imports and outputs, properly checking
all the properties. This situation is different for the state machine logic.
For chapter 4.3, for example, this is not complete.
Probably the designer has been started or completed but we still have to create
links to the requirements.