Knowledge-based Configuration: From Research to Business Cases, FIRST EDITION (2014)

Part IV. Case Studies

Chapter 16. SIEMENS: Configuration and Reconfiguration in Industry

Andreas Falkner and Herwig Schreiner, Siemens AG Österreich, Vienna, Austria

Abstract

Whereas the configuration of consumer products such as PCs, cars, insurances, and such is well understood and supported by commercial tools, large-scale industrial systems still raise considerable challenges concerning modeling, solving, and performance. After a short explanation of the importance of this topic to Siemens, this chapter presents the domain of railway interlocking systems as an example of such complex industrial systems and discusses detailed requirements for their configuration. It then reports on techniques used for solving those requirements at Siemens as well as on results of their application.

Keywords

Knowledge-based Configuration; Reconfiguration; Knowledge Base; Knowledge Evolution; Large-scale Systems; Industrial Systems; Complex Systems; Siemens; Railway Interlocking Systems; Variability

16.1 Introduction

Siemens¹ is a global company that produces a rich variety of products in its four sectors, Energy, Industry, Healthcare, and Infrastructures and Cities, from relatively small items (such as electric power supplies, gear units, etc.) to very complex items (such as power plants, gas turbines, railway interlocking systems, etc.). Many of these products are configurable, either by a Siemens engineer or sales manager who prepares a bid, or directly by a business customer who selects components or features before buying the product.

Depending on the special requirements of the products and production processes, Siemens uses different configurators, some tailor-made (such as Siemens Industry Mall), some using configurators built into Siemens’ product life-cycle management tools COMOS and Teamcenter, and some based on external commercial tools (such as SAP’s Variant Configurator or Internet Pricing Configurator²).

None of those tools was available or well suited for the task of configuring a new type of Siemens railway interlocking system developed in the 1990s. The challenge was to move from an engineer-to-order type of process (suitable for traditional relay interlockings) to a configure-to-order process in order to reduce costs for the new type of electronic interlockings. This posed the following challenges for the configuration system:

• High variability: Many different component types and subtypes (hundreds of types, thousands of attributes), different variants for different countries

• Dynamic data: The number of components is not fixed but is derived only during the configuration process

• High complexity: Network (not only tree) of component connections, complicated restrictions, consistency and completeness conditions, and optimization criteria

• Very large systems (tens of thousands of components)

• Semi-interactive usage: On the one hand, the search for a solution is to be highly automated; on the other hand, the engineers are to be allowed to edit all components and attributes directly in order to cover special requirements

• Long lifespan (more than 20 years): Easy maintenance of the knowledge base, repeated reconfigurations (i.e., updating or extending an existing system) are required

To a large extent, these requirements were similar to those encountered for the configuration of Siemens’ EWSD telephone switching systems. For that purpose, a tailor-made configuration system based on generative constraint satisfaction (Fleischanderl et al., 1998) was used successfully. The core of that system was reimplemented in Java (see Haselböck and Schenner, 2014³ for a description of this framework) and used as a basis to build configurators for electronic railway interlockings and other railway safety systems; see Falkner et al. (2007) for a report on the relevant experience.

The remainder of this chapter presents the domain of railway interlocking systems in Section 16.2 and the requirements that such complex industrial systems impose upon configuration (Section 16.3). Section 16.4 reports on techniques used for solving those requirements with the aforementioned system and Section 16.5 concludes with describing the main effects of their application.

16.2 Domain: Railway Interlocking Systems

Railway interlocking systems ensure safe railway operations. They are used to monitor and control railway stations such as the one shown in Figure 16.1. Fundamental principles of railway interlockings include the following: Signals must not be operated so as to permit conflicting train movements at the same time. Points (switches) and other field elements in a train route must be set to correct positions before a signal may allow train movements to enter that route.

FIGURE 16.1 Large railway hub with shunting tracks.

Electronic railway interlockings consist of thousands of components with hundreds of different types of hardware, software, and interfaces. A railway interlocking can be represented as a network of (possibly repeated) subcomponents, for example: field equipment such as signals, lamps, and cables; computer rooms with hardware racks, frames, and modules of various types and the interconnecting wiring (as shown in Figure 16.2); work places for the traffic controllers with keyboards, screens, and other devices (as in Figure 16.3); software modules for movement control, communications, and interaction, with parameter settings of various kinds.

FIGURE 16.2 Siemens rail automation hardware.

FIGURE 16.3 Siemens’ Controlguide operations control center.

For the configuration of a complete and correct interlocking for a railway station, thousands of constraints (i.e., dependencies between components and/or their attributes) have to be satisfied. There are constraints on the existence and/or number of components and on the values of their attributes, depending on the existence and values of other components; for example, each electric light signal in the field requires the existence of an adequate hardware module, a module of type “M8” can control a maximum of eight lamps, the usage of LEDs excludes other lamp types on the same module, and so on.

The configuration process for a specific station uses information about the field elements (names, track layout, speed limits imposed by properties of the environment such as downward slope, curve radius, etc.) and about the interfaces to neighboring stations and traffic controllers. From this information, all the data (parameters) needed by the railway interlocking system have to be derived and in some cases adjusted by the configuration engineer, taking into account the features provided by the selected technology (type of interlocking system). The engineer has to be informed about the alternatives in order to make an existing inconsistent configuration consistent (e.g., which components to add or delete, which values to change).

Figure 16.4 shows a schematic representation of the configuration of a railway interlocking system. The upper left part represents the station with the railway tracks, points (switches), and signals (similar to a real station as shown in Figure 16.1). The interlocking building depicted next to it contains two hardware racks (similar to real racks as shown in Figure 16.2). The left one (cable termination) wires the cables from the field elements (signal lamps, point machines) to the element control computer (ECC). The frame is equipped with element operating modules (e.g., POM, SOM) and a CPU (central processing unit). The latter contains software that represents the topology and attributes of the field elements (e.g., signal “S1”). The configuration of all hardware and software components must be consistent (e.g., all signal lamps must be connected to a SOM module and be controlled by a process in the CPU). See Falkner and Fleischanderl (2001) for more examples for software and monitoring systems, such as configuration of train routes.

FIGURE 16.4 Schematic representation of a railway interlocking.

In more detail, the necessity of modules is driven by the required functionality (e.g., elements in the field). The UML diagram in Figure 16.5 is a small fraction of the UML model for hardware and software configuration. It shows that an interlocking system is in charge of several railway stations. Each station houses an unlimited number of hardware racks with hardware frames of various types. Some frames contain hardware modules that control field elements. Each element is controlled by a process in a control computer. Depending on its type, an element may require certain functions, which are characterized by a set of input and output bits. Each bit is wired to a specific position (allocation) on a hardware module.

FIGURE 16.5 UML diagram for part of the hardware configuration.

Additional constraints such as the following (not shown in the figure) restrict the allowed combinations: The modules shall be placed in a frame of a suitable type. Depending on their type, certain functions must be allocated to different modules, others to the same module. Certain bits are to be allocated to specified fixed positions (e.g., the first bit on the first register of certain module types).

The goal is to find a minimal solution of racks, frames, and modules for each station when the elements and their functions (including required bits) are given. The scenario is incremental: functionality (and therefore modules) may be added to an existing configuration.

16.3 Requirements

16.3.1 Variability

Although the previous section only gives an overview of the most important components of an interlocking system, it shows the variety and complexity of the problem. There are various subsystems with quite different characteristics, for example:

• Hardware with many types of different components as well as electrical and spatial constraints. As output for manufacturing, CAD drawings are needed.

• Software modules with thousands of configuration parameters which depend on other parameters and on the hardware. They must be output in various formats so that they can be loaded into the PROMs of the electronic interlocking.

• Communication equipment configured to satisfy different network protocols and address spaces.

• Work places for the traffic controllers comprising monitor screens, keyboards, and other devices.

Because railways have a long history and are considered by operators to be a kind of national culture, different countries have different regulations, equipment, and requirements. Therefore, corresponding variants and versions of the configurator application must be developed, deployed, and maintained in parallel.

The applications and use cases range from single installations (market entry in a country) to “mass” production (several stations for one country). In the first case, it is vital to keep the costs for country-specific adaptations of the configurator low, for example, by giving the project engineer much freedom to configure the system according to the country’s special requirements. In the second case, it is vital to keep the costs for station configuration low, for example, by increasing the automation degree of solution finding. This kind of semi-interactive usage (a combination of manual editing and automatic completion) is also important when regulations change and a station configuration has to be adjusted accordingly before the change is implemented in the configurator.

16.3.2 Complexity

The inherent structure of the model is not only a tree as supported by most of the tools that are based on a BOM (bill of materials) structure such as feature modeling (Asikainen et al., 2006). Rather, it is a network, for example, for wiring between hardware components, for train routes in the track diagram on the traffic controller’s screen, and so on. Typically, each element (e.g., signal “S1”) has interacting representations in different subsystems (e.g., lamps in the hardware, parameters in the software, menu items on the traffic controller’s monitor, etc.). This leads to complicated consistency and completeness conditions (e.g. that a train route from one signal to another must be a path of connected elements without loops and with a unique choice of switch positions if alternative paths exist).

Large stations can have hundreds of tracks with a similar number of axle counters or track circuits, hundreds of sets of points (switches) with one or two machines each, hundreds of signals with a total of thousands of lamps, and many other devices such as level crossings and section blocks. All these devices are wired with the computers in the interlocking building where tens of thousands of pins must be connected. The number of elements is multiplied by the different software modules in which they occur. In addition, there are thousands of train routes. Taking into account the fact that all these components may have several attributes and relations (associations) to other components, the number of variables can run up to hundreds of thousands. As most of them are not only Boolean values, but enumerations or integer values, the number of possible configurations is enormous.

The configuration task must be able to handle dynamic growth of the system. The number of components is not known beforehand. Depending on the number of tracks, points (switches), signals, and other elements at the station, hardware racks and modules have to be supplied. The project engineer might decide to pack the modules tightly, or leave a certain amount of slack for future station extensions. In the second case, the user is not interested in a minimal solution and therefore plain optimization algorithms are not useful.

16.3.3 Evolution

Railway interlocking systems have a long lifespan (20 to 40 years). During that time, not only the station layout may change (due to adding or removing tracks, signals, or other equipment) but also the spare parts of the interlocking hardware may be changed to newer versions with different characteristics.

Although the knowledge base is not as volatile as for consumer products, there is a change rate of about 10% per year (based on the number of classes, attributes, and constraints). Most changes are caused by new component types or new software functionality. However, constraints may change as well when regulations change (e.g., longer braking distances required) or when experiences from the operations lead to new procedures for manufacturing (e.g., two modules of a certain type are not to be placed next to each other because the resulting increase in heat might reduce their lifetime). Typically, old types cannot be removed from the knowledge base because they are still in use in existing configurations. Constraints must take into account the possible interrelations between all those old and new components and features. Proper tools for easy maintenance of the knowledge base are required.

If the interlocking system has to be changed, due to either changes of station layout or the replacement of damaged components, an upgrade to the current knowledge base may be necessary. This can lead to constraint violations because the existing configuration no longer complies with the new knowledge base. In some cases, the necessary reconfiguration can be done automatically (such as setting new properties to their default value); in other cases, user decisions are required (e.g., in case an existing hardware module is no longer allowed in its current position, it is either to be moved to another position or replaced by a newer version which is allowed there). Falkner and Haselböck (2013) describe the main issues that arise in such situations and Friedrich et al. (2011) summarize important theoretical and practical aspects of formalizing reconfiguration problems.

16.3.4 Other Issues

The preceding paragraphs concentrate on knowledge representation and reasoning issues of the core configuration task. Of course, the configurator application as a whole has to deal with much more: Sales and pricing topics play a role in the bidding phase, although not as prominently as in consumer products’ configurators. Usability is directed at serving professional engineers, thus the graphical user interface must be clearly understandable and functional but need not be too elaborate. A very important topic is interaction with other systems or data sources: reading information about the station, generating outputs and documentation in various formats for manufacturing, reviews and assessments, access to product data in the management system (e.g., SAP). Last but not least, there are general issues such as authorization, collaboration, database management, version control, and so on.

16.4 Techniques

A short survey of the available commercial configuration frameworks and tools at the beginning of the development project showed that they were either not expressive enough (e.g., supporting only a flat set of variables and constraint tuples) or not efficient enough (e.g., solvers based on backtracking, backjumping, etc.). It was decided to create a powerful generic framework and specialization layers for domain-specific requirements for railway safety systems. See Haselböck and Schenner (2014)⁴ for a detailed description of the generic framework (S’UPREME).

Most of the structures and requirements are similar for different railway companies (e.g., tracks, signals, train routes, etc.). However, they differ in some—sometimes many—details. For instance, sets of available hardware elements are different in different countries, rules about how to connect components vary, or special user interface views or import/export formats are needed. Therefore, the architecture of a S’UPREME configurator for railway safety systems consists of three layers (see Figure 16.6):

• The domain-independent kernel of the S’UPREME framework, providing mechanisms for knowledge base representation, constraint-based reasoning, and generic user interfaces

• The basis layer, containing all railway and technology knowledge that is common to all configurator variants

• The variant layers, representing the specialties of different countries and customers

FIGURE 16.6 Layers of a S’UPREME configurator.

In the basis layer for railway safety systems, some domain-specific implementations deal with special requirements, especially concerning input/output. The configurator reads tables (e.g., Excel) specifying customer requirements and checks their consistency (including cross-references between input tables). A template-based generator for outputs makes it easier to create documentation in various formats (XML, PDF, Microsoft Word, Excel, etc.).

Object-oriented design uses concepts in a modeling language that is highly expressive and allows the implementation of those layers and the representation of the application domain in a natural, understandable way (taxonomy, partonomy, classes, attributes, associations). Therefore it can well deal with the complexity of the domain and with the interfaces to UI and to other systems (import/export). The implementation language is Java and thus platform-independent.

Generative constraint satisfaction extends the object-oriented model with constraint technology. The attributes and associations of the model are used as variables of a constraint satisfaction problem. See Haselböck and Schenner (2014)⁵ for details. Reasoning over those structures is harder than for classical CSP (constraint satisfaction problems). Some provisions enable the system to deal with configurations as large as typical interlocking systems:

• The system manages all dependencies between variables and can therefore update each active constraint on the fly. This is used for showing the user always an up-to-date violation status as well as for a straightforward explanation mechanism.

• The standard solving strategy is a heuristic local search based on a greedy repair mechanism (not a complete search). Violated constraints indicate parts of the configuration that need to be repaired. The user can repair a constraint violation manually by choosing from a list of possible repair steps. Alternatively, the solver can be started to solve the constraints according to the solver’s current heuristic.

• Rules can be used if the inference is always to work in one direction only (e.g., always generating hardware modules for field elements, never generating field elements for hardware modules). In such cases, they are more efficient than constraints. The S’UPREME rule mechanism can be used in parallel with constraints.

• Usually, the configuration of a large system consists of different subtasks (hardware configuration, software configuration, etc.). The constraints of such subtasks can be grouped in clusters that can be deactivated when currently not in the user’s focus. Thus, they are ignored by reasoning until they are activated again.

• Each of those clusters can be assigned a specialized solver. Thus, in order to tackle certain subproblems, optimized (also third-party) solvers can be used (e.g., for solving linear programming (LP) problems).

Reconfiguration is supported by several strategies:

• After upgrading an existing configuration to a new knowledge base version, constraint violations indicate the parts in the configuration that are now outdated and should be reconfigured. These constraint violations can either be repaired manually, giving the user full control over the process, or automatically by special-purpose solvers that try to minimize changes to the configuration.

• By keeping the model of the configurator backward-compatible with all previous versions, it is possible to represent systems that were built years ago.

• In order to improve schema evolution, multistep upgrades have been introduced (i.e., only one user interaction for upgrading a configuration over several schema versions).

Automated regression tests are used to find the differences between the content of a configuration before and after an upgrade to a new configurator version. This enables mistakes in knowledge modeling to be detected at a very early stage and, equally importantly, ensures that the configurations remain stable from one version to the next. This feature is particularly important for railway applications, where all installations—and therefore all changes to existing installations—must run through intensive quality assurance and validation procedures.

There are two groups of regression tests: small test cases, which test partial configurations with respect to one constraint each (typically designed during development), and large test cases comprising many different features in order to get a high coverage of various configurations and values (typically designed by the integration team at the start of the project). Of course, all these tests must be checked and possibly adapted when change-requests are implemented in a new version.

The advantages of using a standard IDE (integrated development environment) such as Eclipse are exploited: It supports knowledge engineering with state-of-the-art editors (code completion, diagrams, etc.), debugging facilities, test environment, and version control.

Iterative and incremental processes for knowledge engineering are important practices to guarantee customer satisfaction and high quality. In particular, they are necessary for correctly modeling the domain and product details as information from various sources has to be integrated: written technical specifications for the numerous parts of the configurable product, (tacit) knowledge of all involved engineers, different languages and representations (e.g., semistructured natural language, logical, graphical). Thus, the early and continuous involvement of domain experts during development of the configurator is crucial for success.

16.5 Results

The amount of configurator code concerning the core task of knowledge representation and reasoning is often overestimated. In the configurator described in this chapter, the model and constraints comprise only about 20% of the source code. The rest of the code deals with the user interface (UI), the generation of outputs (BOMs, documents, CAD drawings, manufacturing plans, etc.), and testing of the whole application.

The layered architecture facilitates reuse considerably. The code size of a typical variant is approximately 10% of the whole application code (a small value, considering that railway companies in different countries have quite different requirements). Standardizing the model and UI (i.e., omitting those packages in the variant layer or reducing them to customization via tables or only overriding certain constraints) has reduced the number of code lines for variants by 40%. Thus, the development time of variants could be significantly reduced as well.

Constraints help the user to avoid mistakes, reducing integration cycles and system test time. Rules and solving steps create objects and set values automatically, leading to productivity increases for the user by a factor of 10 and higher, compared to configuration tools used earlier:

• For a specific country variant, the configuration effort of the first version of an interlocking system could be reduced from eight to two weeks.

• A similar speed-up of 70% for the core configuration process was evaluated in a study of the Siemens business unit responsible for a new type of interlocking system in a country where several stations had to be equipped. They compared the tool for the new technology (which included tables with customer information) with an existing tool for a similar technology.

• With the help of the configurator variant for a new axle counter system (developed in less than a year’s work), the degree of automation with solvable constraints and rules was so high that 95% of the configuration could be derived within a few seconds, once the station layout had been drawn in the tool (requiring only a few hours’ work). Although such a system is much smaller than an interlocking system, it still consists of 50 classes with 300 attributes and associations and 200 constraint definitions. Average configurations consist of 2,000 instances, 30,000 variables, and 30,000 constraint instantiations.

Multistep upgrades have reduced development time for the upgrade by an estimated 50% of the upgrade coding time, as well as the users’ time for upgrading configurations to 1/N for each upgrade, N being the difference between source and target version numbers (i.e., the number of single-step upgrades).

16.6 Conclusion

The sections above have presented the rationale and impacts of using product configuration technologies in a configurator framework for large-scale industrial systems (railway interlockings). All in all, development could be accelerated compared to an alternative where only standard object-oriented programming languages would have been used:

• Multiple usage of constraints (for checking, filtering, explanation, and repair) as well as their compact format reduced the size of the corresponding code parts by approximately 30%.

• Maintenance is easier due to the declarative representation of the constraints (separation from solving algorithms).

• Schema evolution and automatic database upgrade could be implemented more easily.

• Training time of new knowledge engineers was reduced to approximately one half.

• Compared to an analogous rule-based system, an estimated 20% of bugs were avoided.

Thus, configuration technologies can definitely help to reduce project costs.

References

1. Asikainen T, Männistö T, Soininen T. A unified conceptual foundation for feature modeling. In: 10th International Software Product Line Conference (SPLC 2006). Baltimore, MD: IEEE Computer Society; 2006;31–40.

2. Falkner A, Fleischanderl G. Configuration requirements from railway interlocking stations. In: 17th International Joint Conference on Artificial Intelligence (IJCAI-2001), Configuration Workshop, Seattle, WA. 2001;15–17.

3. Falkner A, Haselböck A. Challenges of knowledge evolution in practice. AI Communications. 2013;26(1):3–14.

4. Falkner A, Haselböck A, Schenner G, Schreiner H. Benefits from three configurator generations. In: Innovative Processes and Products for Mass Customization (Proceedings of the joint conference of the International Mass Customization Meeting 2007 (IMCM’07) and International Conference on Economic, Technical and Organizational Aspects on Product Configuration Systems (PETO’07)). GITO 2007;89–103. Series on Business Informatics and Application Systems vol. 3.

5. Fleischanderl G, Friedrich GE, Haselböck A, Schreiner H, Stumptner M. Configuring large systems using generative constraint satisfaction. IEEE Intelligent Systems. 1998;13(4):59–68.

6. Friedrich, G., Ryabokon, A., Falkner, A.A., Haselböck, A., Schenner, G., Schreiner, H., 2011. (Re)configuration based on model generation. Second Workshop on Logics for Component Configuration (LoCoCo 2011), Perugia, Italy, pp. 26–35.

7. Haselböck A, Schenner G. S’UPREME. In: Felfernig A, Hotz L, Bagley C, Tiihonen J, eds. Knowledge-based Configuration – From Research to Business Cases. Waltham, MA: Morgan Kaufmann Publishers; 2014:263–269. (Chapter 22).