Patterns in industrial automation at Siemens - Frances Paulisch/Lutz Dominick

Various operating divisions at Siemens are investigating the effectiveness of using patterns to improve their software production and these activities are coordinated through our department. Many of the software design patterns that are not subject to non-disclosure are being published by our colleagues in [8]. In this section, we focus on our particular project where we are investigating the effectiveness of applying patterns to technologically-oriented applications like the process control of steel mills.

Identifying an initial set of patterns

Our project team, the ``pattern mentors'', consists of two (software) pattern specialists and two (industrial automation) domain specialists. The first step was to identify potential patterns in interviews with domain experts and then to iteratively refine them (again in consultation with domain experts). In each round we focused on a specific knowledge area. We invited the experts to give a short introductory talk about the solutions they used in their projects and we introduced the notion of patterns. Then we had a discussion to discover the patterns that the projects teams had been using intuitively. Roughly three interviews were required to finish a set of patterns. In their final form, the domain experts agreed that the pattern met our two major criteria of:

• correctly representing the problem-/solution-pair and
• being a useful representation of knowledge demanded by their projects.

As an additional ``sanity check'' we also presented several patterns to experts of a different but related area who had not taken part in the discussion. The level of detail used in the pattern-form was found to be appropriate for providing an understanding of the related areas.

The current state of our project is such that the final proof, the evaluation of the effectiveness of these patterns in concrete steel mill projects, has not yet been achieved, but we are working towards this goal. Our work demonstrates that a small team of people with knowledge of both patterns and of the domain can build up a set of domain-specific patterns which serve as a basis for demonstrating the effectiveness of patterns to the domain experts. Once such a set of essential patterns has been identified and the domain experts have agreed to the effectiveness of their representation in pattern-form, how should one go about extending the set of patterns?

Identifying additional patterns

Ideally, a domain expert should be the pattern author because they have the best knowledge of the domain, but there are several hindrances which must be overcome to accomplish this. The domain experts

• need time to learn what patterns are and how to identify and use them,
• need practice at abstracting away detail and writing patterns, and
• are so tied up in their daily projects that they find it hard to take the first hurdle and actually write patterns.

Making patterns available online

To make the patterns more accessible and attractive to the domain experts, we recorded all of our patterns in HTML in a platform-independent online catalog of patterns. This catalog was organized as a set of three axes which relate to the application domain (in our case the level of automation, the physical structure of the milling machine, and the product-quality features of the milled steel).

The online catalog allows the use of multiple entry points, navigation among the patterns, and a hierarchical structure. The navigation aspect is especially important when the pattern collection grows larger than about 50 patterns which can no longer be linearly organized in book-form. We used links to hide information which is not immediately relevant to the user so that they can see that the information is there if they want it, but are not distracted by it. Furthermore, many terms are connected to an online glossary which resulted from a partial domain analysis of the application area. It is too early to tell how useful this online collection of patterns is to the domain experts, but initial indications are positive.

Initial experience in using patterns

Our initial experience in using patterns indicates that patterns are more likely to be accepted and applied if a significant portion of the design is covered by either a group of low-level patterns or a single higher-level ``architectural'' pattern. Our users expect some kind of tool support, especially when they are faced with ca. 30 or more patterns. In cases where no appropriate technological design pattern is judged to be ideally suited, the users tend to choose structure-oriented patterns such as ``pipe-and-filter'' or ``layered architecture'' over process-oriented patterns.

Future directions

Many of the realizations made within the software reuse community, such as

• the importance of high-level management commitment, and
• the effectiveness of making a strict distinction between the teams responsible for developing components and those responsible for identifying and maintaining them

We have noticed a strong relationship between the technological design patterns and software design patterns. The technological design patterns we have discovered thus far are planned to serve as the basis for a software application framework for the process-automation of steel mills. Here, we are particularly interested in investigating the interplay between the technological and the software design patterns (e.g. representing the process-control of a conveyor belt as a pipe-and-filter architecture).