Control engineering system for controlling an industrial process having a multilayered runtime framework

Abstract

The problem addressed by the present invention is that of specifying a control engineering system, in particular for track-bound traffic, that easily renders non-functional requirements on the control engineering system configurable and providable for the control engineering system. According to the invention, this problem is solved by a control system for controlling an industrial process, in particular a control system for an industrial production facility or for controlling traffic, in particular track-bound traffic, comprising: a) a product instance for the software of the control system that controls the control requirements on the industrial process; b) a control system platform for executing an instance of the control system, the control system platform having a runtime framework comprising the following components: c) a core instance (RTF core) capable of providing a runtime framework that allows execution of application functions, e.g. train tracking, logging, etc., distributed over a plurality of monitored processes, i.e. in a monitored thread in each case; wherein d) a workplace instance (RTF workplace) is configured in a manner building on the RTF core, said RTF workplace extending the RTF core situated on the lowermost logical layer and supporting the implementation of client applications; and e) a further logical layer with an ensemble instance (RTF ensemble) building on the logical layer of the RTF core is provided, said further logical layer containing auxiliary functions that facilitate the implementation of server applications, preferably those auxiliary functions that in the context of a distributed server system are relevant to the execution of the software of the control system.

Description

[0001] Control system for industrial process control with multi-layer runtime framework

[0002] The present invention relates to a control system for controlling an industrial process, in particular a control system for an industrial production plant or for controlling traffic, in particular rail-bound traffic.

[0003] In rail-based transport, trains travel along the railway network along routes that are requested by a control system at the dispatching train control level. This request can be triggered automatically if the trains are running according to schedule and a sequence of previously planned routes is therefore planned. In the event of deviations from the timetable or other deviating interventions, the routes are requested manually by the train dispatcher. Each requested route is only set by a control unit (central or decentralized) when the track elements (switches, signals, block clearance detection, moving block in the ETCS) for this route are available and can be set accordingly and blocked against other use by competing routes. After the route has been traveled orof the route elements contained therein, this blocking is lifted again and the route elements are available again for setting new routes.

[0004] Such control systems are often implemented in a client-server architecture, as shown in Figure 1. A control center contains control stations (see "Workplace Clients" in Figure 1) that display the current situation of the railway infrastructure, including the train route, to the dispatcher. These stations allow them to intervene and initiate various actions using a graphical user interface as needed. These stations interact with server systems ("Ensemble Servers") that network control stations at one or more locations with the associated interlocking systems in a railway infrastructure area and, if necessary, implement various automatic train control algorithms.

[0005] A major challenge with such control systems is not only developing the client and server applications with the necessary quality characteristics, but also operating them. In other words, this means that in addition to the actual railway control functionality, various non-functional aspects must also be considered. These concern, on the one hand, direct customer expectations and, on the other hand, implicit expectations regarding the development process itself, which in turn impact product quality (maintainability, testability, etc.).

[0006] The following non-exhaustive list of quality features summarizes the generally most important points for train control software or the train control system: i) very high reliability requires measures to handle typical error cases and, when errors occur, their appropriate disclosure with, if necessary, also information on error handling ii) very high availability requires measures to handle partial system failures (e.g. redundancy, restoration, etc.) and their disclosure iii) high security (SIL 0 to SIL 2) requires measures to safeguard the information basis on which the system makes automatic decisions or allows manual intervention by a user, as well as safeguarding the correct execution of decisions made.Examples of this are no processing of incorrect configurations, no processing of incorrect messages to or in the system, cross-comparison of calculated decisions of the system, etc. iv) Cyber ​​security requires measures in relation to access / intervention control, identification of sources that trigger changes in the system and the disclosure of relevant events in the system, etc. v) High maintainability and extensibility require measures in the development process of the software components, but also basic concepts for the development of software components, which ideally manifest themselves concretely in the code base of a software vi) High testability and validation requires measures in the development process but also basic concepts for the development of software components, which ideally manifest themselves concretely in the code base of a software.

[0007] Due to the associated normative specifications, these quality characteristics apply across products, for example product lines within the Siemens Group, but also across different manufacturers, as well as across subsystems (client / server and other subsystems).

[0008] Since the regulation of rail transport is often still associated with proprietary national train control and train guidance systems, software applications for servers and clients in this environment are often developed in isolation, despite the aforementioned requirements, and then gradually integrated into an overall system. Furthermore, measures related to the aforementioned quality characteristics are implemented directly in the respective software applications (see the various control technology solutions A and B in Figure 2). This is done partly using OSS / COTS solutions and partly through specially implemented special solutions. Each application is subsequently tested and validated as a complete package, and maintained as a complete system after handover to the customer.

[0009] This effect is further amplified when considering solutions from one manufacturer for a variety of customers, or when considering solutions for the same customer problem (e.g., a reliable, safe train control system) from different manufacturers. This results in specialized individual solutions that essentially aim to satisfy similar customer needs with similar quality features.

[0010] The present invention was therefore driven by the following core problems: i) Train control systems implemented to date are developed with a focus on functional requirements and make strong assumptions about how customers intend to operate their railway systems. ii) Software products for train control systems are assembled from highly specialized sub-solutions and must be maintained and operated in this form. Each subsystem uses different technologies and sometimes different concepts to address the non-functional requirements that are actually system-wide.

[0011] This harbors a risk of the following undesirable effects: i) Products are continually "reinvented" and developed to meet customer-specific requirements based on existing products. ii) Known problems are sometimes solved with newly invented solutions. This means that the reusability of software components that solve known problems is limited. iii) Each product must be developed, documented, tested, validated, operated and maintained individually as a complete package. iv) Project managers, developers, testers, validators, etc. specialize in the products or their subsystems (client / server) and their properties. Development, maintenance and operation require a high degree of specialist knowledge not only in relation to the products themselves, but also in relation to whether the overall software component is client or server.v) Difficult structuring / separation between domain-specific specialist functions for train control technology and generally applicable measures for ensuring the quality characteristics listed above. vi) Cross-cutting non-functional requirements are difficult to address.

[0012] Even with "generic control technology products," such as the "Controlguide Iltis N" control technology system developed by Siemens, strong, domain-specific assumptions are made about how the customer operates its systems. They therefore focus heavily on the functional system requirements of a train control system (see Figure 3). While functional and non-functional requirements are defined generically, they are individually adapted for the products of, for example, customer A and customer B, and can certainly develop completely differently. As already discussed above, this has the consequence that train control systems in other countries or by other customers can sometimes be difficult to meet if the functional customer needs deviate too significantly from the specifications of a "generic product." Special products for the customer are therefore derived from standard products.Thus, today's development focuses on client-side or server-side application development for specific customer requirements. The corresponding software applications are developed by separate teams using separate tools, libraries, and sometimes different workflows, and then integrated into a complete system.

[0013] For example, if code functions are to be used on both the client and server sides, they are outsourced and made available in external libraries, or client-side code uses server-side functions, or vice versa. Depending on the development history, necessary functions (e.g., security-related measures) are developed separately on both the client and server sides, potentially at least twice, and sometimes implemented differently despite the same objective. This is further complicated by the fact that server and client code are sometimes implemented in different programming languages ​​and development frameworks.

[0014] This results in comprehensive, integrated development being impossible or at least significantly more difficult. Consequently, development teams are heavily specialized in either server or client areas.

[0015] The present invention is therefore based on the object of specifying a control system, in particular for rail-bound transport, with which it is possible to make non-functional requirements for the control system easily configurable and available for the control system.

[0016] This object is achieved according to the invention by a control system for controlling an industrial process, in particular a control system for an industrial production plant or for controlling traffic, in particular rail-bound traffic, comprising: a) a product instance for the software of the control system controlling the control requirements of the industrial process; b) a control system platform for executing an instance of the control system, wherein the control system platform has a runtime environment (Runtime Framework) comprising the following components: c) a core instance (RTF Core) which is capable of providing a runtime environment which enables application functions, such as train tracking, logging, etc., to be distributed across several monitored processes, ieeach in a monitored thread; d) a workplace instance (RTF Workplace) is designed on the core instance, which extends the core instance located on the lowest logical layer and supports the implementation of client applications; and e) a further logical layer with an ensemble instance (RTF Ensemble) is provided on the logical layer of the core instance, which has auxiliary functions that facilitate the implementation of server applications, preferably those auxiliary functions that are relevant for the execution of the control system software in the context of a distributed server system.

[0017] In this way, when developing such a control system, general, non-functional aspects are no longer treated as secondary and are no longer addressed with dedicated software, but are made available as part of the functional software components in the control system in the dedicated runtime framework via the various instances that each solve specific tasks.

[0018] In a practical embodiment of the present

[0019] According to the invention, train tracking and logging can be executed as application functions in the core instance. Other important application functions for a railway control system can also be executed here.

[0020] In a further particularly advantageous embodiment of the present invention, each application function can be modularized as a runtime component and decoupled from other application functions, wherein each application function can optionally be distributed as desired among different processes and, if necessary, can also be executed multiple times.

[0021] The developers of the application functions can be supported in an advantageous manner via the core instance by providing tools for developing an application function using the core instance, by means of which, for example, communication can take place locally on the computer and / or monitored subthreads or timers can be started.

[0022] Furthermore, it can be important for system stability if the core instance, in addition to measures for monitoring and detecting errors, also provides means for automatically restoring partial functions after an error occurs.

[0023] Furthermore, both the operators and the developers of such a control system can be advantageously supported if, depending on the configuration, a specific product in the core instance can perform system checks at startup time or at periodic intervals, such as checks for the fill level of a hard disk, checks for the status of a RAM, and checks for possible data corruption on the file system. In a further advantageous embodiment of the invention, it can be provided that the logical layer of the workplace instance is configured to have auxiliary functions that can preferably be used for starting and operating monitored GUI applications, for providing reliable acoustics for messages from client applications, and / or for managing user profiles or user sessions.

[0024] In the ensemble instance, it can also be advantageous to provide auxiliary functions such as status synchronization between servers and / or the operation of redundant application functions on the client and / or server side. Furthermore, additional auxiliary functions are helpful for the operator and developer in this ensemble instance because they no longer need to be implemented in the actual functional control technology applications.

[0025] Further advantageous embodiments of the present invention can be found in the remaining subclaims.

[0026] Advantageous embodiments of the present invention are explained in more detail with reference to the drawings.

[0027] Figure 1 shows a schematic overview of a control system for rail-bound transport in client-server architecture according to the state of the art; and

[0028] Figure 2 shows a schematic overview of a control system for rail transport in a client-server architecture with various solutions A and B for the control system according to the state of the art; Figure 3 shows a schematic overview of a control system for rail transport in a generic client-server architecture with various solutions A and B for the control system as well as its functional and non-functional requirements according to the state of the art;

[0029] Figure 4 shows a schematic view of a three-layer runtime framework for a control system for rail-bound transport according to the present invention; and

[0030] Figure 5 shows a schematic view of a runtime framework designed according to the three-layer structure in Figure 4 for a control technology environment for rail-bound transport with various instances of the control technology software according to the present invention.

[0031] A key concept in the control system described here according to the present invention is to focus on the non-functional requirements of a train control system and to address these using a specialized software framework. This framework consists of a dedicated runtime environment that executes and monitors product-specific specialized functions in a modularized manner (without knowing them or restricting their type). The runtime framework itself remains free of any domain specifics and merely offers various additional functions, for example, to implement reliable communication, redundant runtime components, or reliable UI displays (i.e., no specialized functions).

[0032] As shown in Figure 4, the Runtime Framework is constructed from three logically distinguishable instances: 1. RTF Core

[0033] The lowest layer with the core instance of this runtime framework implements a runtime environment which enables application functions such as train tracking, logging, etc. to be distributed across multiple monitored processes, i.e. each executed in a monitored thread. Each application function is thus modularised as a runtime component and decoupled from other application functions. Each application function can be distributed across different processes as required and executed multiple times if required. RTF Core offers a variety of tools for developing an application function, which can be used, for example, to communicate locally on the computer, to start monitored subthreads or timers, etc. In addition to measures for monitoring and detecting errors, this lowest layer of RTF Core also implements various measures for the automatic recovery of subfunctions after an error occurs.Depending on the configuration of a specific product, additional system checks can be performed at startup or periodically, e.g. hard disk fill level, RAM status, data corruption on the file system, etc.).

[0034] Platform RTF Workplace

[0035] Building on this lowest layer, RTF Workplace is defined, which extends the lowest layer, RTF Core, and supports the implementation of client applications. This means that the RTF Workplace layer offers various auxiliary functions, such as starting and running monitored GUI applications, reliable acoustics, and handling user profiles or user sessions.

[0036] Platform RTF Ensemble

[0037] Similarly, the RTF Ensemble layer is defined based on RTF Core. This layer provides various auxiliary functions that facilitate the implementation of server applications, especially those relevant in the context of a distributed server system. Examples include state synchronization between servers or the operation of redundant application functions.

[0038] Products (examples above are Controlguide Iltis N or Iltis D from the Siemens Group) can now develop their server and client applications based on the Runtime Framework, comprising RTF Core, RTF Workplace and RTF Ensemble.

[0039] This structure standardizes the development of client and server application functions. On the one hand, functions can be implemented in such a way that they can be reused in both client and server applications, and on the other hand, the corresponding application development is standardized. This simplifies the exchange between the client and server development teams.

[0040] Similarly, specialized functions can be implemented that can be shared between products. Employees who worked on a single product (development, testing, validation, etc.) also "speak" a common language and can contribute to multiple products. Accordingly, the associated workflows and processes can also be better standardized.

[0041] Furthermore, not every product needs to solve similar problems individually, but can rely on standardized mechanisms of the runtime framework. These can be continuously improved and expanded independently, thus benefiting all subsystems of the runtime framework.

[0042] As mentioned in the previous section, the present invention, with its associated runtime framework, focuses on the non-functional requirements currently placed on a scheduling train control system. This differentiates the present invention from the approach of a "generic product" for train control technology, as explained above, which focuses on the functional requirements and the specialist functions derived from them. In the inventive implementation, this means that the underlying requirements are addressed by a "cross-cutting" solution that is actually "cross-cutting," as shown in detail for a control system with a runtime framework in Figure 5.

[0043] The invention makes it possible to create a common basis for the development of both client and server applications across different products, as well as to implement established concepts and measures to ensure the aforementioned quality features, on the basis of which reliable train control technology products can be developed.

[0044] The particular advantages of a control system for rail transport structured in this way are as follows: i) Measures to ensure software reliability can be implemented once at the runtime framework level and also validated there. For example, a mechanism can be provided that checks code or individual configuration files of a software application for tampering, which can be a very important process, especially when patching the software application, depending on their safety-related relevance. ii) The modularisation and testability of the product application is ensured and promoted by the standardised framework API. iii) Errors in implemented RAMS measures and other basic functions can be detected at a single point in the runtime framework orits surrounding systems, such as a Common Library, a Common GUI framework and the Common Foundation, instead of having to do this in the server as well as the client application software. iv) Due to the unified runtime environment in the core instance RTF Core, application functions can be implemented in such a way that they can be used on both the server and the server side or, if necessary, shared across products. v) Products are completely free in the implementation of their specialist functions and can decide independently whether a specialist function can be shared with other products or whether they want to adopt existing specialist functions from other products, adapt them or replace them with new functions. vi) Specialists work on the basis of a common basis and can achieve more despite (or because of) a lower level of specialization. vii) An alternative solution would be to rely on existing COTS or OSS runtime environments.While the corresponding solutions partially reference the quality characteristics listed in Section 1, they have no normative background related to train control systems. A significant disadvantage, however, is that, on the one hand, there are no guarantees regarding the long-term availability of these software packages, and, on the other hand, often only parts of the desired quality characteristics can be directly addressed. viii) Furthermore, the concept of the (runtime) framework for handling non-functional requirements in train control technology does not contradict the possibility of implementing the functions of the runtime framework completely or partially using OSS and / or COTS solutions.

Claims

Patent claims 1. Control system for the control of an industrial process, in particular a control system for an industrial production plant or for the control of traffic, in particular rail-bound traffic, comprising: a) a product instance for the software of the control system controlling the control requirements of the industrial process; b) a control system platform for executing an instance of the control system, wherein the control system platform has a runtime environment (Runtime Framework) which comprises the following components: c) a core instance (RTF Core) which is capable of providing a runtime environment which enables application functions, such as train tracking, logging, etc., to be distributed across several monitored processes, ieeach in a monitored thread; d) a workplace instance (RTF Workplace) is designed on the core instance, which extends the core instance located on the lowest logical layer and supports the implementation of client applications; and e) a further logical layer with an ensemble instance (RTF Ensemble) is provided on the logical layer of the core instance, which has auxiliary functions that facilitate the implementation of server applications, preferably those auxiliary functions that are relevant for the execution of the control system software in the context of a distributed server system.

2. System according to claim 1, characterized in that train tracking and logging can be executed as application functions in the core instance.

3. System according to claim 1 or 2, characterized in that Each application function can be modularized as a runtime component and decoupled from other application functions, whereby each application function can optionally be distributed among different processes and executed multiple times if required.

4. System according to one of claims 1 to 3, characterized in that the core instance provides tools for developing an application function, by means of which, for example, communication can take place locally on the computer, monitored subthreads or timers can be started.

5. System according to one of the preceding claims, characterized in that the core instance, in addition to measures for monitoring and detecting errors, also provides means for automatically restoring partial functions after an error occurs.

6. System according to one of the preceding claims, characterized in that, depending on the configuration, system checks can be carried out by a specific product in the core instance at startup time or at periodic intervals, such as for example the fill level of a hard disk, the state of a RAM and possible data corruption on the file system.

7. System according to one of the preceding claims, characterized in that the logical layer of the workplace instance is designed to have auxiliary functions which can preferably be used for starting and operating monitored GUI applications, for providing reliable acoustics for messages from the client applications and / or for handling user profiles or user sessions.

8. System according to one of the preceding claims, characterized in that a status synchronization between servers and / or the operation of redundant application functions on the client and / or server side are provided as auxiliary functions.

Images