Part 1 of this blog entry discussed software modeling, modeling notation, and modeling tools. But, what does this have to do with Functional Safety?  The IEC 61508 standard has requirements, for certain SIL levels, regarding the use of:

• “Semi-formal methods”
• Computer-aided specification and design tools
• Design standards
• Performance modeling
• Model-based test case generation
• Model-based testing
• Static modeling
• Dynamic modeling

These requirements can be fully or partially met through the use of a modeling notation such as UML, and the tools enabling its use.

If modeling notations and tools are not properly used by competent personnel, then unclear, unmaintainable, untestable, incomplete, and/or incorrect models could lead to safety issues.  It is important to decide what type of information, and what level of information, various parts of a model are required to capture, then to express that information in a clear and complete manner.  One mistake organizations make in adopting UML modeling to support analysis and design is to assume that defining model objects and drawing the diagrams using those objects is all that is required to create a complete design.  Although models are generally created to represent an application design, the models themselves must be designed to accomplish their goals (clarity, completeness, accuracy, etc.).  Creating a design model, which is not well-designed itself , is similar to writing code at the implementation level, that runs, but is difficult to understand/maintain/test due to lack of attention to style, organization, incomplete commenting, etc.  Code modules usually have comments and “function headers” to provide a better understanding of the responsibilities of a function, the semantics of parameters, the preconditions for calling the function (e.g., “file must be opened for write”), etc.  At higher levels of design (i.e., UML model) supporting text is also necessary, whether it’s supplied in a document or in a model.  The context and presentation of the text are just as important as the text itself.  For example, a description of why a particular design approach was taken may be “buried” in a field that can only be viewed in a modeling tool, by navigating down 3 levels of nested dialog boxes.

The conventions and techniques used in a model developed by multiple people should be well understood by all modelers.  Documenting these in a “design standard” is one way to establish consistency.

UML helps a great deal with documenting design in that it is a broadly understood notation.  However, certain types of information and explanations are not always easily expressed with just the notation available in UML.  For example, most (if not all) modeling tools provide description fields associated with modeling objects (diagrams, classes, associations, components, etc.) to assist with explanation.  Stereotypes and “Note objects” can also be defined and used to help with the presentation of explanatory text.  Much of the structure, flow, timing, associations in a design can be represented in UML, to specify that they must exist, but English explanations are needed to show why they exist, why a specific design approach was taken, why alternative approaches were not taken, how different parts of the achieve design goals, etc. (i.e., all the things that UML cannot express well).  Alternatively, this information could be found in a section of a design document, which is generated from the model.

The IEC 61508 standard encourages modeling because it can be a powerful means to improve the development process, and therefore bolster the systematic capability of a design.  If you design your model to have the appropriate level of detail, clarity and organization, you will benefit greatly from the advantages modeling tools have to offer.