Working efficiently with a standardized language

With new developments, engineers often apply proven designs, with or without minor modifications. So why do they still fail to deliver solutions that customers demand? Usually, communication is the major stumbling block. High Tech Institute trainer Eric Burgers explains how SysML helps to successfully communicate design ideas for complex systems. Eric Burgers teaches the course Introduction to SysML and System modelling with SysML.

In an ideal situation, a project starts with perfect requirements: unambiguous, specific and precise, and just enough to describe the problem to be solved, with sufficient room for creativity and innovation. The designs meeting these requirements are complete, specify decomposition, behavior and collaboration completely and are 100 percent consistent and testable in all respects. Ultimately, a system is delivered according to the requirements and fulfilling its intended use.

In a nightmare version, a project departs from inconsistent or contradictory requirements, containing phrases like “the system will facilitate …” or “contribute to …”. The system boundary is difficult to define. The whole is decomposed into vague components, such as (categories of) devices or even arbitrary groups of “things.” Desired behavior, if specified, appears to be separate from the design or is factually incomplete, leaving much room for interpretation. In the ultimate nightmare version of a project, a system is built that’s not based on the actual design. Defects are repaired by piling note upon note, making the design file an absolute mess. Only when everything is read in the correct order can the actual design be derived.

                   

Boehm’s second law of engineering: during a software project, costs to find and fix bugs get higher as time goes by.

Most projects aren’t complete nightmares but neither are they ideal. Created designs don’t always meet all requirements and may contain inconsistencies, omissions or other defects. These defects are a potential source of failure costs: defects introduced during requirements analysis or design become more expensive to fix the later they’re resolved. All while they could have been prevented.

This raises a point of conflict: designs are meant to mitigate the risk of building wrong or faulty systems, yet projects very often create designs that don’t reflect the customer’s requirements, thus defeating the whole purpose of a design. Why is this and what can be done about it?

Bottom-up approach

Projects come in all shapes and sizes and solve simple to challenging problems. Relatively simple, small projects aren’t too difficult to complete. The risk of failure increases as a project becomes more complex. The complexity of a project is related to the complexity (in terms of size or difficulty) of the product being made and the size of the organization making it.

Large(er) projects are often organized into discipline-specific development groups. These groups do discuss their interfaces with each other, but there’s usually no overarching approach to describing how to integrate all the components into one working whole. Sometimes it even seems that interfaces are created ad hoc.

This has all the traits of a bottom-up approach, where discipline-specific parts are first designed and produced and then assembled in the hopes of getting a working product. Such an approach may work for less complicated projects where engineers can understand the entire product with all its details. When parts can affect each other through their behavior or properties, however, it can be difficult to assess how the whole will behave, especially if the building blocks come from different disciplines.

The risks of increasing complexity

Drawings

One way to deal with large, complex projects is to create extensive documentation to disseminate design ideas to all engineers involved. In technical fields such as mechanical engineering, software engineering, industrial automation and civil engineering, there are often standardized ways to do this. In practice, documentation is supplemented by drawings made in popular tools such as Powerpoint or Visio (Windows) or Omnigraffle (Mac OS). In addition, Excel is used to exchange large amounts of information.

In multidisciplinary projects, the use of supplementary drawings and other project-specific tools increases to bridge the gap between the disciplines. In principle, there’s nothing wrong with this; the transfer of design ideas and information between disciplines is badly needed. Without bridging the interdisciplinary gaps, a project will encounter serious integration problems. However, “project-specific” also means repeatedly inventing the wheel, especially when the work is done by consortia that change from project to project.

Another problem with these drawings is that there’s no general agreement on what they should represent. Moreover, there’s no guarantee that they’re complete and consistent. As a result, there’s a real risk that the drawings, although clear to the author, may be misinterpreted by readers, which in turn leads to defects in the product that aren’t discovered until later stages of the project.

Very often this way of working and the associated integration problems are simply accepted. As the project approaches the completion date, the problems are resolved through rework or patching, or they’re simply left in the project as “future work.” An alternative approach is to standardize the communication of design ideas on a project or even company basis. This has the disadvantage that the conventions are ‘local’ to the project being undertaken – each participant will have to learn them.

It makes more sense to adopt an industry standard, including supporting tools. Then the conventions only need to be learned once to be applied many times, regardless of the project or organization. All the better if the standard allows documents and drawings to be replaced by a single source of truth that’s always up-to-date.

Modeling language

The complexity of projects, or technology in general, is only increasing. Think of the difference between the first phones and today’s smartphones. Or compare the first cars with the vehicles seen on the road today. While the main function has remained the same (communicating, driving), today’s systems are increasingly integrated into a larger whole to provide users with additional services that can’t be provided by the systems themselves. This trend has been identified and described in many sources, including the vision documents of Incose – Vision 2025 and more recently Vision 2035.

To cope with the increasing degree of integration, Incose is promoting the transition to model-based systems engineering (MBSE). This involves using models to design and verify complex systems. One of the first steps toward MBSE is the adoption of a language suitable for building such models. SysML is one such language.

SysML allows the representation of different types of systems and their behavior, as well as their interactions with the environment.

The Systems Modeling Language (SysML) is a general-purpose modeling language designed to help engineers develop and document complex systems with a large number of components. The language is widely used in industries such as aerospace, automotive, infrastructure and defense. The graphical notation provided allows the representation of different types of systems and their behavior, as well as their interactions with the environment. This enables engineers to effectively and efficiently communicate their ideas and ensure that all those involved in the development process have the same understanding of the product to be built. Because the language isn’t discipline specific, systems can be described at an overarching level.

The four pillars of SysML

1. Structure: a system can be decomposed into smaller parts, which have interfaces with each other.
2. Behavior: three types of behavior – flow-based, event-based and message-based – can be specified and related to one another.
3. Requirements: system requirements and their tests can be defined.
4. Parametrics: once described, a system can also be simulated.

                   

Increased precision

When using SysML, the first thing you’ll notice is that the designs are more precise and thus require extra work to complete. However, that precision also ensures that everyone involved can interpret the designs in the same way as the author and that defects and omissions are much easier to identify and prevent. Because it’s almost impossible to create an inconsistent design, failure costs are avoided. If these costs exceed the initial investment, there’s a business case for using SysML.

Implementing SysML can come across as a daunting task. At first glance, it can seem like a considerable challenge to mold an entire complex system into a model suitable for analysis and simulation. In practice, the transition is often incremental and organizations gradually apply SysML more and more to describe designs. Slowly but surely, documents are either being replaced by models or become views on the model, until at the higher levels of maturity, there are no documents at all because all information is encapsulated in models.

As SysML is a comprehensive language, it takes time to master all the details. Proper training will speed up adoption considerably. Engineers will certainly also have to get used to the increased precision with which designs are created from the start. Once successfully adopted, SysML will improve design communication and quality.

For specifications with a lot of geometric information, as often created in civil engineering, SysML is less effective. The language lends itself particularly well to cyber-physical, software-intensive systems. A good example is an infrastructure project in Amsterdam-Zuid, where the designs were created by the supplier and reviewed by the acquiring party. Here, the use of SysML resulted in a significant increase in development speed, with the number of defects found being significantly lower than average. Also elsewhere, SysML is proving that it can prevent nightmares and bring projects closer to the ideal.

This article is written by Nieke Roos, tech editor for Bits&Chips.