EP4343538A1 - Verfahren zur bereitstellung einer softwarekonfiguration für eine modulare fabrik - Google Patents

Verfahren zur bereitstellung einer softwarekonfiguration für eine modulare fabrik Download PDF

Info

Publication number
EP4343538A1
EP4343538A1 EP22197397.7A EP22197397A EP4343538A1 EP 4343538 A1 EP4343538 A1 EP 4343538A1 EP 22197397 A EP22197397 A EP 22197397A EP 4343538 A1 EP4343538 A1 EP 4343538A1
Authority
EP
European Patent Office
Prior art keywords
function module
function
service
derived
module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22197397.7A
Other languages
English (en)
French (fr)
Inventor
Mario Hoernicke
Sten Gruener
Katharina Stark
Nicolai SCHOCH
Nafise Eskandani
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ABB Schweiz AG
Original Assignee
ABB Schweiz AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ABB Schweiz AG filed Critical ABB Schweiz AG
Priority to EP22197397.7A priority Critical patent/EP4343538A1/de
Priority to CN202311232884.9A priority patent/CN117762509A/zh
Priority to US18/473,480 priority patent/US20240103471A1/en
Publication of EP4343538A1 publication Critical patent/EP4343538A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/31—Programming languages or programming paradigms
    • G06F8/315—Object-oriented languages

Definitions

  • the present invention relates to a method of providing a software configuration for a modular plant.
  • Modular plants are becoming more and more established due to benefits in respect to development costs and material efforts.
  • a standardized methodology methodology called Modular Type Package (MTP) is commonly known in the prior art.
  • MTP Modular Type Package
  • This approach creates a framework for interoperability between so-called function modules and a suitable orchestration system for developing a modular plant and technical processes inside such a modular plant, wherein technical components of a modular plant to be developed are depicted by using function modules of various types.
  • the function module concept is evolving to develop plants in a modular fashion, but without the need of having to stick completely to the MTP standard.
  • the EP 3937012 A1 discloses the development and usage of such function modules.
  • function module concept is lacking an efficient re-use of function modules that have originally been build for a certain technical application to be used in another field of technicial application, in order to make the development of technical modular plants or technical processes for technical modular plants more efficient.
  • a method of providing a software configuration for a modular plant comprising:
  • the core idea behind the present invention is to develop the already known type-instance MTP approach when using function modules (FM) further. This is done in the present invention by implementing a full object-oriented approach for function modules that is based on an inheritance concept applied for function modules which are used for developing technical modular processes or technical modular plants.
  • Inheritance in the present invention can be used to derive previously defined functionality features from a parent function module and extend it with further (optional) functions. However, in the present invention, it is further possible to forbid inheritance of a specific function module, by sealing said function module.
  • a so-called basic functionality or (basic) function of a derived child function module can be from another (parent) function module and the parent functionality may be changed (partly), if allowed, without having to implement another function module again.
  • the concept of the present invention further includes abstraction of function modules, which are known as classes in object-orientation approach, implementation and usage of semantically defined interfaces as well as the enforement and disablement of functions applied to a function module in an efficient way, so to allow usage of a function module for different or multiple technical applications in an easy way.
  • function modules which are known as classes in object-orientation approach, implementation and usage of semantically defined interfaces as well as the enforement and disablement of functions applied to a function module in an efficient way, so to allow usage of a function module for different or multiple technical applications in an easy way.
  • An interface of a function module in the present invention may be a rule or an instruction for a derived or inherited function module which functions of function features must be implemented by said dervice function module.
  • an interface does not say, how a certain feature, e.g. a service or an equipment, of a parent function module is to be implemented in a derived child function module.
  • the interface may be a rule that is defined at a location or in a parent function module and the implementation of the interface occurs in another (derived) function module.
  • said interface could be used to define a signature of a service or a usage of an equipment or a device inside a function module. Every function module implementing the interface must provide the defined services with the defined signature.
  • a signature of a service according to the present invention is a description of characteristic behaviour of a certain service.
  • a service of stirring may be defined by its characteristic behaviour or input parameters such as velocity of the stirring process and the time for stirring.
  • a function (feature) or a functionality (feature) of a function module may also be named as a service in the present invention.
  • a service according to present invention can be virtual or non-virtual.
  • a service When a service is marked as being virtual in a (parent) function module, it only provides information of what the service does, e.g. stirring of a liquid, but it does not say how this service is implemented.
  • the implementation of such a virtual service has to be done by the derived child function module that inherits said virtual service. Implementation can mean providing the essential code lines for said service.
  • a semantic description of a function module according to the present invention provides a description of what said function module really does or the functionality of said function module.
  • the applied concept to function modules allows function modules in an advantageous manner to signalize which basic or optional functionality of a derived child function module can be changed and which functionality is not allowed to be changed.
  • This functionality of a function module is implemented by using so-called protected services and protected equipment or devices.
  • a protected service or a protected equipment or device can only and exclusively be used in a derived child function module in which said protected service or said protected equipment occurs, but said protected feature or protected equipment can not be used in a further instance of said derived child function module.
  • a protected service or a protected equipment may be changed in said derived child function module.
  • the present invention enables an enforcement of a derived child function module for an actual implemenation. This is done by so-called abstract function modules, as described further below.
  • the improved concept of the present invention allows that function modules can be easily adapted for multiple usage in different fields of technical application, reducing the efforts in developing said function modules and resulting in a more cost- and time-efficient developing process when developing technical modular processes or technical modular plants using such function modules of the present invention.
  • the function information of the first function module comprises at least one service defining at least a basic function of the first function module that is inherited by the derived at least second function module.
  • the at least one service comprises a signature which comprises at least a characteristic property of said service.
  • the function information of the first function module further comprises at least one device used to implement said defined service.
  • the first function module further implements at least an interface information only defining said service that must be implemented by the at least derived second function module.
  • the function information in said derived second function module comprises a protected feature that allows to adjust, whether a defined basic function of a service and / or a device from the derived second function module can be used in a further instance of said derived second function module.
  • the at least first function module further comprises at least a conditional feature that allows activating/enforcing or disabling the usage of the device and / or service of the first function module and / or the derived second function module.
  • the service comprises at least one optional feature.
  • the advantage achieved is that the functionality of the service can be easily enhanced.
  • the at least second function module comprises a selection function allowing to enforce or disable the usage of the optional function of the service derived from the at least first function module.
  • the at least second function module comprises a sealed feature allowing to disable inheritance of the at least second function module.
  • the service is a virtual-typed service meaning that the at least derived second function module must implement the at least service inherited from the parent first function module.
  • the advantage achieved is that the first function module needs not contain detailed information about an implementation manner.
  • a computer comprising a processor configured to perform the method of any preceding aspect.
  • a computer program product comprising instructions which, when the program is executed by a processor of a computer, cause the computer to perform the method of any of the first and second aspects.
  • Fig. 1 illustrates a schematic flow-diagramm of a method 100 of providing a software configuration for a modular plant.
  • a first function module 10 as a parent object is provided, wherein the first function module 10 comprises a function information of the first function module 10.
  • a second function module 12 is generated, wherein the second function module 12 is a derived child object of the first function module 10 that inherits the function information of the first function module 10.
  • Fig. 2 illustrates a schematic relationship between a parent function module 10 and a derived child function module 12.
  • the child second function module 12 inherits the functionality of the parent first function module 10.
  • the functionality of the first function module 10 can be described by at least one service, at least one equipment or device.
  • the device executes or controls the service.
  • the service can be further defined by at least one parameter or argument.
  • the parent first function module 10 can have multiple functions, but it needs not to provide any information of its concrete implementation.
  • the implementation information meaning how a service or functionality must be implemented may be contained or placed in the derived second function module 12.
  • Such a service is also called as a virtual service in a parent function module.
  • a service of a (parent) function module may be a measuring a parameter, such a temperature of a gas, by an equipment or device as a sensor.
  • the signature of the service would be the time of how long the measurement should be performed.
  • Another second example would be a stirring process in a melting pot.
  • the stirring would be the service described in a corresponding (parent) function module.
  • the velocity of stirring or the duration of time of stirring would correspond to the signature of said service of stirring.
  • the corresponding equipment or device in this example would be the stirring device.
  • the core idea of the present invention is to apply the concept of object-orientation to function modules that can be used and adapted for the development of a technical modular process or a technical modular plant.
  • a function module can be easily adapted to different fields of technical application. This allows multiple und different usage of an existing or stored function module in an efficient way without the need to develop completely new function modules any time, the field of application changes.
  • a function module is comparable to a class in the object-orientation approach.
  • a service that is implemented in a function module can be compared to a method.
  • Procedure parameter is comparable to method arguments.
  • An equipment or the attributes of an equipment
  • report values, configuration parameters, and process values can be compared to attributes.
  • the function information of the first function module 10 comprises at least one service defining at least a basic function of the first function module 10 that is inherited by the derived at least second function module 12.
  • a basic function of a service could be heating or measuring.
  • the at least one service comprises a signature which comprises at least a characteristic property of said service.
  • a signature of that service or a characteristic property could be a time duration of the heating process or a temperature as input parameter that needs to be received after a certain amount of time.
  • the function information of the first function module 10 further comprises at least one device used to implement said defined service.
  • the device or the equipment is configured to control the defined service.
  • the first function module 10 further comprises at least an interface information only defining said service that must be implemented by the at least derived second function module 12. Therefore, an equipment in a parent first function module 10 is not always necessary. Hence, it could be also possible that the parent first function module 10 only defines a service by a signature and the derived child second function module 12 contains the information of the detailed implementation of that service.
  • the function information in said derived second function module 12 comprises a protection feature that allows to adjust, whether a defined basic function of a service and / or a device in the derived second function module 12 can be changed. In this way, a restrictive feature to adapt the second function module 12 in an easy manner is realized.
  • the at least first function module 10 further comprises at least a conditional feature or functionality that allows activating/enforcing or disabling the usage of the device and / or service of the parent first function module 10 or the derived second function module 12.
  • the advantage achieved is that the at least first function module 10 or the derived second function module 12 can be easily adapted for different uses.
  • the service comprises at least one optional feature.
  • the advantage achieved is that the functionality of the service can be easily enhanced besides the basic features or basic services of a function module 10, 12.
  • the optional features or services are only described in the derived second function module 12, but not in its parent function module 10.
  • the term "basic feature” corresponds to the term “basis service”.
  • the at least second function module 12 comprises a selection function allowing to enforce or disable the usage of the optional function of the service derived from the at least first function module 12.
  • the at least second function module 12 comprises a sealed feature allowing to disable inheritance of the at least second function module 12.
  • the advantage achieved is to allow an easy restrictive use of the at least second function module 12.
  • the service is a virtual-typed service meaning that the at least derived second function module 12 must implement the at least service inherited from the parent first function module 10.
  • the first function module 10 needs not contain detailed information about an implementation manner.
  • the parent first function module 10 contains a service called heating as a virtual service and the derived second function module 12 contains the detailed information about how the service of heating is implemented, e.g. an gas or an oil heating.
  • virtual services could be implemented, which would allow a derived class to override and redefine the functionality of a service. Additionally, virtual could be used for equipment, such as a pump, where several different implementations could be used and by a derived module, the specific implementation could be described (see Interface).
  • An abstract function module can be a kind of a template that already defines all basic functions for the function module, but the services are only described by means of their signature.
  • the derived function module has to implement the services (or just some of the services), before the function module can be used.
  • the abstract function module cannot be directly used, but another function module must be derived from it. Still, abstract classes may provide several preimplemented methods.
  • an equipment or a device in a function module can also be made protected, would mean, the equipment can only be used in derived function modules, but not manually controlled in the POL.
  • Private service can be used to define functionalities for structuring the function module internally. No other function module or POL is allowed to access the private service. Private are basically all internal functions and variables of a function module.
  • the novel feature is the enablement of state-based service control also for internal services in a function module. This provides the advantage to allow more fine-granular access to services by the module vendor just be changing a keyword.
  • Function module interfaces can be used to define the needed services to provide a certain functionality. That means, the function module interface only defines which services should be there and the signature of the services. A function module implementing an interface must adhere and implement exactly that interface. How the implementation is done is decided by the implementing function module. Furthermore, a function module can implement multiple interfaces, e.g., pumping and heating, allowing classification of function module "capabilities" and their standardization.
  • a function module can provide services with the same name, but with different procedure parameter (method arguments). Depending on which signature is called, the corresponding control logic is executed.
  • derived function modules can either enforce the usage of optional functionality or nested modules from its parent function modules, or completely disable these functions - or, of course, keep them optional (three-value logic of feature management).
  • a definition of public, private, protected process equipment can be used. That means that similar functionalities like for the services can be used. Examples here are parts of an equipment which are completely hidden from the operator or need to be made transparent, e.g., due to a service agreement.
  • same function module can be sold to customer A as a black-box allowing no customer-maintenance, while customer B can get same function module where parts of equipment are defined public allowing their dedicated monitoring (e.g., using OPCUA) and maintenance/replacement.
  • the inheritance mechanisms for function modules can not only be used in a "binary" way, i.e., by enabling/disabling services etc. but also to restrict the modeling space of inherited function modules, e.g., by narrowing the range of possible variables like ranges of service parameters or setting some default parameters for services or equipment.
  • Fig. 3 illustrates a schematic example for depicting inheritance of a function module.
  • inheritance can be used to derive functionality from an already developed function module.
  • the functionality - the services - can be inherited and used in the derived FM.
  • a function module "SeparatorType" is shown, which is inherited by the function module “OWSeparator”.
  • the service “Maintenance” is defined as protected and is therefore only usable in the function module "SeparatorType" and the derived function modules, here "OWSeparator”.
  • the function module "OWSeparator” can reuse the services from "SeparatorType” and further specify the functionality for the desired purpose. Additionally, the HMI, alarm list, tags and tag list is derived from the inherited module. These functions can be enhanced, as well, but not be reduced, since this is process equipment that must be present to fulfill the functions of the function module. HMI can be changed (symbols can be rearranged) for the derived module when adaptation is needed.
  • Fig. 4 illustrates a schematic interface implementation in a function module.
  • a function module interface can be defined for the separator.
  • the function module interface specifies all required services, as well as their state-machine and the needed parameters. It does not define a complete function module.
  • the "SeparatorType" implements the interface and therefore the service "Produce” must be implemented, as well.
  • Fig. 5 shows an example for the separator function module interface.
  • the interface defines a service "Produce” that must be implemented in every function module using it. Additionally, the state-machine must be implemented in exactly the way it is defined in the interface and the service must provide exactly one parameter called “OilLevel” and one process value output "ProcValX”.
  • Fig. 6 illustrates a schematic implementation of an abstract function module which is a further possibility to implement a service.
  • the example of Fig. 6 also includes a definition of a virtual service, which must be implemented in the derived function module.
  • the Fig. 6 shows the "SeparatorType” as abstract FM, and a virtual service "Commissioning".
  • the service commissioning must be implemented by the derived function module "OWSeparator”.
  • the function module "SeparatorType” cannot be used for plant engineering, instead the derived function module "OWSeparator” has to be used.
  • Fig. 7 illustrates a schematic implementation of a sealed function module.
  • a sealed function module means that a further inheritance of said function module is disabled and that this function module is the last level of inheritance.
  • the function module "OWSeparator" is defined sealed, which means no other (child) function module can be derived from it.
  • Fig. 8 illustrates a schematic implementat of enforcing and disabling functions of a function module.
  • the optional functionality, and the nested modules and nested function modules can be enforced. This means, the engineer cannot disable the enforced functionality anymore, also, not in derived function modules.
  • the function module "OWSeparator” shall be used to separate oil and water. That means, the water treatment that is defined as option functionality in the "SeparatorType”, is enforced by the "OWSeparator”.
  • a possible implementation is shown in Figure 8 . It is noted that feature variation is orthogonal to the implementation. This means that enforcing "WaterSeparation" may enable inclusion of a specific interface/virtual service or a concrete service implementation.
  • Fig. 5 shows an example, how with a derived function module, the optional functionality, and the nested modules and nested function modules can be disabled. That means, the engineer using the derived function module cannot enable the functionality anymore. Also, not in derived function modules.
  • the "OWSeparator” shall be used to separate oil and water. That means, the gas treatment that is a nested function module in the function module "SeparatorType”, is disabled by the "OWSeparator".
  • the concept of the present invention provides a method for a full object-oriented concept for handling function modules in the following way:
  • the method also allows function module interfaces and definition of abstract function module in the following way:
  • the method of the present invention further allows enforcing and disabling inherited optional functionality and nested function modules and MTP modules:

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computing Systems (AREA)
  • Stored Programmes (AREA)
EP22197397.7A 2022-09-23 2022-09-23 Verfahren zur bereitstellung einer softwarekonfiguration für eine modulare fabrik Pending EP4343538A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP22197397.7A EP4343538A1 (de) 2022-09-23 2022-09-23 Verfahren zur bereitstellung einer softwarekonfiguration für eine modulare fabrik
CN202311232884.9A CN117762509A (zh) 2022-09-23 2023-09-22 为模块化工厂提供软件配置的方法
US18/473,480 US20240103471A1 (en) 2022-09-23 2023-09-25 Method of Providing a Software Configuration for a Modular Plant

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP22197397.7A EP4343538A1 (de) 2022-09-23 2022-09-23 Verfahren zur bereitstellung einer softwarekonfiguration für eine modulare fabrik

Publications (1)

Publication Number Publication Date
EP4343538A1 true EP4343538A1 (de) 2024-03-27

Family

ID=83438932

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22197397.7A Pending EP4343538A1 (de) 2022-09-23 2022-09-23 Verfahren zur bereitstellung einer softwarekonfiguration für eine modulare fabrik

Country Status (3)

Country Link
US (1) US20240103471A1 (de)
EP (1) EP4343538A1 (de)
CN (1) CN117762509A (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040015822A1 (en) * 2001-03-23 2004-01-22 Linton Samuel W. Method and apparatus for dynamic assembly and verification of software components into flexible applications
US9829881B2 (en) * 2001-06-22 2017-11-28 Schneider Electric Software, Llc Supervisory process control and manufacturing information system application having an extensible component model
EP3937012A1 (de) 2020-07-09 2022-01-12 ABB Schweiz AG Konfiguration einer modularen anlage

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040015822A1 (en) * 2001-03-23 2004-01-22 Linton Samuel W. Method and apparatus for dynamic assembly and verification of software components into flexible applications
US9829881B2 (en) * 2001-06-22 2017-11-28 Schneider Electric Software, Llc Supervisory process control and manufacturing information system application having an extensible component model
EP3937012A1 (de) 2020-07-09 2022-01-12 ABB Schweiz AG Konfiguration einer modularen anlage

Also Published As

Publication number Publication date
CN117762509A (zh) 2024-03-26
US20240103471A1 (en) 2024-03-28

Similar Documents

Publication Publication Date Title
US9829881B2 (en) Supervisory process control and manufacturing information system application having an extensible component model
US8464227B2 (en) Process control script development and execution facility supporting multiple user-side programming languages
US11687062B2 (en) Configuration of a modular plant
EP4343538A1 (de) Verfahren zur bereitstellung einer softwarekonfiguration für eine modulare fabrik
Selic Tutorial: real-time object-oriented modeling (ROOM)
US10303144B2 (en) Object creation in process control systems
CA2245156C (en) Service logic portability based on interface definition of execution environment in an intelligent network
CN111651149A (zh) 一种便于部署的机器学习模型系统及其调用方法
Strassner et al. TMF white paper on NGOSS and MDA
Hofer et al. Behavioral customization of state machine models at ESO
Cruz Salazar et al. Applying core features of the object-oriented programming paradigm by function blocks based on the iec 61131 and iec 61499 industrial automation norms
EP4303727A1 (de) Integration von nicht-mtp-modulen
Fitzgerald et al. rApps: Transforming Network Management with Intelligent Automation Apps
KR100642476B1 (ko) 객체지향 기술을 이용한 지능망 플랫폼 개발 방법
Andrade et al. Engineering components for flexible and interoperable real-time distributed supervision and control systems
Willner et al. IN service creation elements: variations on the meaning of a SIB
Lee et al. The architecture of generic VNFM using TOSCA
CN113326481A (zh) 一种项目代码自动构建打包方法、装置、系统及介质
CN117111960A (zh) 工业现场设备监测系统
Andrade et al. A Management Tool for Component-Based Real-Time Supervision and Control Systems
Langsford Object modelling for OSI management
Ilić et al. Towards Automated Model-Driven Development of Distributed Communicating Systems and Communication

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR