Process control engineering system for controlling an industrial process, including a multilayered runtime framework and configurable system performance examination

Abstract

The invention relates to a process control system for controlling an industrial process, in particular a process 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 process control system that controls the process control requirements on the industrial process; b) a process control system platform for executing an instance of the process control system, the process 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, such as, for example 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, building on the core instance, said RTF workplace extending the core instance 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 core instance 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 process control system, and f) in at least part of the instances previously mentioned measures can be executed that serve to examine the system, preferably also to monitor or detect errors in client applications, wherein this system examination can be configured in an XML file for a selection of the desired instances or also for all instances and / or for client applications run on the respective instances and can be activated by means of this XML file.

Description

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

[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 traffic, trains travel on the railway network along routes that are requested by a control system at the 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 deviations, 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 from other use by competing routes. After the route has been traveled or...of 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 built using a client-server architecture, as shown in Figure 1. A control center contains control stations (see "I ltis Workplace" and "IBS 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, if necessary. These control 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, where appropriate, 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 relate, on the one hand, to direct customer expectations and, on the other hand, to 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 faulty configurations, no processing of faulty 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 which 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 traffic is often still accompanied by proprietary national train protection and train control systems, software applications for servers and clients in this environment are often developed in isolation, despite the above requirements, and then gradually integrated into an overall system. Furthermore, measures relating to the quality characteristics mentioned 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 using specially implemented special solutions. Each application is then 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] A solution to this problem proposed in European patent application EP 23191236.1 is therefore driven by the following core issues: 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 are maintained and operated in this form. Each subsystem uses different technologies and sometimes different concepts to address the non-functional requirements that are essentially system-wide.

[0011] This harbors a risk of the following undesirable effects: i) Products are continually "reinvented" and developed to suit the customer's specific needs on the basis of 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 is a client or server component.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) The 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 the Siemens Group, 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 1 above). Functional and non-functional requirements may be defined generically, but they are individually adapted for the products of, for example, customer A and customer B, and can 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 greatly from the specifications of a "generic product". Special products for the customer are therefore derived from standard products.

[0013] 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 are then integrated into a complete system.

[0014] If, for example, 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 on both the client and server sides (e.g., security-related measures) are developed separately, i.e., they may be developed at least twice, and sometimes implemented differently despite having the same objective. What makes this more difficult is that the server and client code are sometimes implemented in different programming languages ​​and development frameworks.

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

[0016] The solution proposed in the above-mentioned European patent application therefore provides 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.

[0017] In detail, this objective is achieved 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 that controls 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) that includes the following components: c) a core instance (RTF Core) that is capable of providing a runtime environment that 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.

[0018] In this way, during the development of 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. Building on such a control system, however, the task still remains to be able to perform the necessary checks and verifications on the control system at regular intervals. In addition, certain checks should also be able to be performed before client applications have fully started. A corresponding implementation of such a verification mechanism is called system examination.Since this is usually a Java application, it would also be desirable to perform process- and / or computer-specific checks in each process.

[0019] Currently, such checks are carried out individually and using dedicated software components, which often has the disadvantage that certain components / applications are started in a certain order and only relatively late in the startup process, which is why special services have to be installed to carry out certain checks beforehand.

[0020] The present invention is therefore based on the object of specifying 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, with which it is possible to embed the so-called system examination in a simple and arbitrarily variable manner in the start process and / or the processes for executing applications.

[0021] 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, the control system platform having a runtime environment (Runtime Framework) comprising the following components: c) a core instance (RTF Core) which is capable of providing a runtime environment which makes it possible to execute application functions, such as train tracking, logging, etc., distributed across a plurality of monitored processes, ie each in a monitored thread;d) a workplace instance (RTF Workplace) is designed on the basis of the core instance, which extends the core instance located on the lowest logical layer and supports the implementation of client applications;and e) building on the logical layer of the core instance, a further logical layer with an ensemble instance (RTF Ensemble) is provided, which has auxiliary functions that facilitate the implementation of server applications, preferably auxiliary functions that are relevant for the execution of the control system software in the context of a distributed server system, and wherein f) in at least some of the aforementioned instances, measures for system examination, preferably also for monitoring and detecting errors in client applications, are executable, wherein this system examination is configurable in an XML file for a selection of the desired instances or also for all instances and / or for client applications executed on the respective instances and is activatable by means of this XML file.;

[0022] In this way, a system is created with which the so-called system examination—that is, the verification of system components in hardware and / or software, or also of subsystems and the client applications running and / or executed on them—can be configured centrally and executed according to the configuration at a specified time during a system start and / or subsystem start. This allows specific system examinations to be provided or defined at each hierarchical level of the overall system and / or client applications, which can be configured or activated in the same XML file.

[0023] In an advantageous embodiment of the present invention, depending on the configuration, system checks can be performed at startup or at periodic intervals using the XML file in the core instance. For example, the fill level of a hard disk, the state of RAM, and system examinations aimed at possible data corruption on the file system can be performed.

[0024] In a further advantageous embodiment of the present invention, a system examination can be implemented via a special interface, wherein the special interface is published in an API and wherein the respective system examination can be implemented by means of usable dependency definitions for all instances of the control system as well as for the client applications that are based on the control system platform.

[0025] In a further advantageous embodiment of the present invention, it can be provided that, prior to the client application's startup, checks can be performed based on the system examination defined in the XML file. Thus, the system examination routines can be initiated according to the configured data in the XML file before the application starts, and the corresponding steps can be initiated based on the results of the executed routines, such as triggering a success or failure event and their further processing.

[0026] It can be particularly valuable for the administration and definition of the system examination if the XML file can be administered and / or configured centrally within the control system platform, which means that the control of the so-called safeguards can be carried out simply, uniformly and centrally.

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

[0028] Advantageous embodiments of the present invention are explained in more detail with reference to the drawings, in which:

[0029] Figure 1 shows a schematic view of a runtime framework (runtime environment) consisting of three layers for a control system for rail-bound transport;

[0030] Figure 2 shows a schematic view of a runtime framework (runtime environment) designed according to the three-layer structure in Figure 1 for a control technology environment for rail-bound transport with various instances of the control technology software;

[0031] Figure 3 shows a schematic representation of the runtime environment with exemplary system examinations (safeguards) embedded in the RTF core;

[0032] Figure 4 shows a schematic representation of the start-up sequence of the runtime environment and the distribution of responsibilities during the start-up; and

[0033] Figure 5 shows a schematic representation of a sequence of a system examination within the framework of the configured safeguards.

[0034] A key concept behind the control system described here is to focus on the non-functional requirements of a train control system and address them using a specialized software framework. This so-called runtime framework comprises a dedicated runtime environment that executes and monitors product-specific specialized functions in a modularized manner (without knowing them or restricting their nature). 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).

[0035] As shown in Figure 1 below, for example, two different versions of the control system program (here ILTIS® N and ILTIS® D of the Siemens Group) can be executed in a platform containing the Runtime Framework for the ILTIS® product, whereby the Runtime Framework is constructed from three logically distinguishable instances:

[0036] 1. RTF Core

[0037] 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 executed across multiple monitored processes, i.e. each 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 various 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.).

[0038] Platform RTF Workplace

[0039] 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 managing user profiles or user sessions.

[0040] Platform RTF Ensemble

[0041] 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.

[0042] 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.

[0043] This structure standardizes the development of client and server application functions. As shown in Figure 2, 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 means that exchanges between the client development team and the server development team are simplified. Analogously, specialist functions can be implemented (see the requirements in Figure 2 below and the functional requirements for product A and for product B in Figure 2 above), which in the case of the requirements of the runtime framework (see Figure 2 below and the dashed arrows pointing in the direction of the functional requirements of product A and product B) can be shared between the products. Employees who worked on a product (development, testing, validation, etc.) also "speak" a common language and can contribute to multiple products. Accordingly, the associated workflows and processes can be better standardized.

[0044] Furthermore, not every product needs to solve analogous 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.

[0045] 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 implementation according to the invention, 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.

[0046] The invention thus 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.

[0047] 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 which checks code or individual configuration files of a software application for falsification, which can be a very important process, particularly when patching the software application, depending on its 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 RAMSS measures and other basic functions can be detected at one 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 standardized 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 to implement their specialist functions and can decide independently whether a specialist function can be shared with other products or whether they want to take over 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. Although the corresponding solutions partly refer to the quality characteristics listed in Section 1, they have no normative background in relation to train control systems. A major disadvantage here, however, is that on the one hand there are no guarantees whatsoever regarding the long-term availability of these software packages and on the other hand often only parts of the desired quality characteristics can be addressed directly. viii) Furthermore, the concept of the (runtime) framework for dealing with 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.

[0048] Such checks of all kinds mentioned above (generally called system examinations) are thus greatly simplified in terms of their configuration and executability due to their centralized configurability and administration, as shown in Figure 3. The system examination is found there as the "Safeguards" block in the RTF core layer and includes, for example, three individually configurable checking applications. "JVM Memory Monitoring," for example, stands for checking the state of definable memory instances in the runtime environment. The further system examination, "Hardware Disk Monitoring," is self-explanatory and concerns the configured checks of the hardware memory.And a box «* Some System Examinatin» concerns all the routines that can be configured within an XML environment (even within a single XML file) and can thus provide the desired checks of the system or parts of it and of definable client applications.

[0049] Figure 4 shows a schematic representation of the system examination sequence when the runtime framework is started up and shows the distribution of responsibilities between the actual control technology product and the runtime environment of the control technology product, according to the color coding in the legend. The "executePreLaunchSystemExamination" calls the relevant checking mechanisms, which have been defined, for example, in the XML file representing the safeguards. If the start process is not successful, it is aborted and reported back as a "SafeguardEvent" to the corresponding control technology workstation (launcher) from which the check was called. The checks (system examination) are passed to the so-called RuntimeCoreLauncher via dependency injection and can therefore be executed regularly. The sequence of this procedure is also shown in Figure 5.

Claims

Patent claims 1. Control system for controlling an industrial process, in particular a control system for an industrial production plant or for controlling traffic, in particular rail-based 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, the control system platform having 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 executed distributed across a plurality of monitored processes, ie each in a monitored thread;d) a workplace instance (RTF Workplace) is designed on the basis of the core instance, which extends the core instance located on the lowest logical layer and supports the implementation of client applications;and e) building on the logical layer of the core instance, a further logical layer with an ensemble instance (RTF Ensemble) is provided, which has auxiliary functions that facilitate the implementation of server applications, preferably auxiliary functions that are relevant for the execution of the control system software in the context of a distributed server system, and wherein f) in at least some of the aforementioned instances, measures for system examination, preferably also for monitoring and detecting errors in client applications, are executable, wherein this system examination is configurable in an XML file for a selection of the desired instances or also for all instances and / or for client applications executed on the respective instances and is activatable by means of this XML file; 2. System according to claim 1, characterized in that, depending on the configuration, system checks can be executed by the XML file 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.

3. System according to claim 1 or 2, characterized in that the system examination can be implemented via a special interface, wherein the special interface is published in an API and wherein the respective system examination can be implemented by means of usable dependency definitions for all instances of the control system as well as for the client applications that are based on the control system platform.

4. System according to one of the preceding claims, characterized in that before the client applications are started, checks can already be carried out on the basis of the system examination defined in the XML file.

5. System according to one of the preceding claims, characterized in that the XML file can be administered and / or configured centrally within the control system platform.

Images