WO1999035568A2

WO1999035568A2 - Isolation of resources from application in a process control system

Info

Publication number: WO1999035568A2
Application number: PCT/SE1998/002301
Authority: WO
Inventors: Håkan Larsson
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 1998-01-09
Filing date: 1998-12-14
Publication date: 1999-07-15
Also published as: SE9800037L; WO1999035568A3; AU2080299A; CA2317417A1; SE521585C2; SE9800037D0

Abstract

The present invention relates to a resource module (38, 40, 42), a resource platform comprising a resource module, an application resource system comprising a resource platform, a process control system comprising an application resource system, a computer program product containing program code for realizing a resource module and a method of isolating a resource from an application. The resource is associated with one of the resource types and comprises said resource module as well as a physical resource (32) and/or an interface to the physical resource (30), at least one action handler for handling a specific action to be performed, by the application, on or for the physical resource and a registrator for registering itself and associated actions handlers (f1, f2, f3) in a register (46) associated with the application, so that the aplication can call an action handler in the resource module for performing an action specialized for the resource type on or for a physical resource.

Description

METHOD AND DEVICES IN A PROCESS CONTROL SYSTEM

OR

ISOLATION OF RESOURCES FROM APPLICATION IN A

PROCESS CONTROL SYSTEM

TECHNICAL FIELD

The present invention generally relates to the field of process control systems and how to interconnect such systems with resources used in them. The present invention more particularly relates to a method of isolating resources from an application in a process control system, a resource module, a resource platform and an application resource system for registering at least one resource in a process control system as well as such a process control system and a computer program product comprising computer program code for realizing at least one such resource module .

DESCRIPTION OF RELATED ART

When connecting different resources to an application, for instance in a computer or telecommunication system, there are several ways of connecting resources to an application running on one central computer. In the case of a telecommunication system such resources can be different physical resources such as boards of different types or boards implementing different functions such as generation of tone signals and signaling as well as boards containing switch cores or part of switch cores. There exists within the field of both computer systems and telecommunication systems a need of isolating the resources used from the application using the resources in order to be able to change resources and upgrade systems.

US-A-5 548 731 describes a computer network comprising a data link interface that is common for several frameworks. The interface comprises a network device driver, network and network services. This document discloses the connection of a physical device to a framework via drivers for driving the physical device. The document also discloses how to go about connecting the physical device to a framework.

W093/25962 discloses a system where a local task running on a local computer can use a remote task running on a remote computer. The local task there uses a handle for establishing contact with the remote task in the remote computer. The computers have here already established some kind of contact or means for establishing contact before the remote task of the remote computer is used.

EP-A-424 758 discloses a method of sharing serially reusable resources among a number of processes. A handle is here used for indicating which resource is to be used. There is no indication of which type a resource is and therefore all resources have to be the same.

US-A-5 313 578 discloses a computer system, where different processes running simultaneously on a network of computer systems communicate variable size data blocks between each other. A calling process acquires a message handler to be used for indicating to which process a certain data block belongs. This handle is thus associated with the data being transmitted and not with any function to be run on or for the resource or the type of function.

JP-A-7 114 476 discloses interwindow communications between windows using memory handles.

EP-A-752 646 discloses a system for changing the byte representation used for different computers in a computer network, where the computers share the same device driver. A handle is here used to point out in which way data is supposed to be read. All of the resources mentioned above are in each case of one type only. There does however exist a problem of connecting such resources when they are of different types, that is if they contain different functions and have different hardware requiring different type of information. There is no way that an application can differentiate between different types of resources in the documents mentioned above.

US-A-5 388 258 describes a telecommunication system including a software structure in which the present invention might be realized. It also describes the use of modules for controlling physical resources or the handling of communication with such physical resources in a telecommunication switching system.

SUMMARY OF THE INVENTION

The present invention solves the problem of enabling isolation between an application run in a process control system and at least one resource that the application uses, when the resource is one of several possible types.

This problem is solved through each resource comprising a physical resource as well as at least one resource module associated with one resource type and the resource module comprising at least one action handler for handling a specific action to be performed, by the application, on or for the physical resource. The resource module registers itself with associated action handlers in a register associated with the application, so that the application, when being run, can call a specific action handler in a resource module for performing an action specialized for the resource type on or for the physical resource.

One object of the present invention is thus to provide a method of isolating a resource from an application, where both are provided in a process control system and the resource is one of at least two different types. This object is solved by a method of isolating at least one resource from an application. Each resource comprises a physical resource as well as at least one resource module associated with one of the resource types. The resource module comprises at least one action handler for handling a specific action to be performed, by the application, on or for the physical resource. The method comprises the step of: registering, each resource module with associated action handler in a register associated with the application, so that the application, when being run, can call a specific action handler in a resource module for performing an action specialized for the resource type on or for the physical resource.

Another object of the present invention is to provide a resource module, a resource platform comprising such a resource module, an application resource system comprising such a resource platform and a process control system comprising such an application resource system for registering a resource in or for an application in the process control system when the resource is one of at least two different types.

This object is achieved by a resource module, a resource platform comprising such a resource module, an application resource system comprising such a resource platform and a process control system comprising such an application resource system, where the resource comprises said resource module as well as a physical resource and/or an interface to the physical resource. The resource module is associated with one of the resource types and comprises at least one action handler for handling a specific action to be performed, by the application, on or for the physical resource, and a registrator for registering itself and associated actions handlers in a register associated with the application, so that the application, when being run, can call an action handler in the resource module for performing an action specialized for the resource type on or for a physical resource. Yet another object is to provide a computer program product for providing registering of a resource in or for an application in a process control system when the resource is one of at least two different types.

This object is achieved by a computer program product comprising: a computer usable storage medium having computer program code embodied in said medium for causing the assembly of sets of executable computer instructions which are part of the process control system to perform association of physical resources to the process control system. The process control system comprises an application and resources and each resource is one of the two types and comprises at least one physical resource and/or and interface to said physical resource. The product has an organizer for organizing sets of executable computer instructions into at least one resource module associated with one of the resource types, so that the resource module comprises at least one action handler for handling a specific action to be performed, by the application, on or for the physical resource and a registrator for registering itself and associated action handlers in a register associated with the application, so that the application, when being run, can call an action handler in the resource module for performing an action specialized for the resource type on or for a physical resource.

The registration is performed in order to loosen the connection between the application in the process control system and at least part of the actual physical resource it is run on while at the same time taking the resource type into consideration. In this way isolation of an application run in a process control system from the resources used by that application is obtained. The advantage of this arrangement is that the application need not be changed when the process control system is to be run on a new physical resource. This makes the adaptation of the software in the process control system to the physical resource it is to be run on easier and therefore large amounts of money can be saved from being spent on unnecessary software development.

The invention will now be described with the help of preferred embodiments and with reference made to the appended drawings.

BRIEF DESCRIPTION OF DRAWINGS

Fig. 1 shows a block schematic of a process control system according to the invention, fig. 2 shows a block schematic of a resource platform according to the invention connected to an application support system, fig. 3 shows a block schematic depicting a system administration as well as a resource control in a resource platform, which control is connected to a platform handler, a physical resource via a resource interface and an application support system, fig. 4 shows a resource module according to the invention, fig. 5 shows a flow chart depicting a method of registering a resource in an application according to a first embodiment of the invention fig. 6A shows a first part of a flow chart depicting a method of registering a resource in an application according to a second embodiment of the invention, fig. 6B shows a second part of the flow chart depicting the method of registering a resource module according to the second embodiment and fig. 7 shows a flow chart of a method of performing an action on a resource registered in an application.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Fig. 1 is shows a block schematic of a process control system according to the present invention. The process control system is provided in a computer system and is arranged to be run, according to a preferred embodiment of the invention, in a telecommunication system and then preferably arranged to handle an exchange, like for instance a private branch exchange, although other types of fields of use can be contemplated. The computer system mainly comprises an application 10, an application support system (ASU) 12, an application resource system (ARE) 16 and an open telecom platform (OTP) 14. The application 10 and the application support system 12 jointly take care of the setting up of telecommunication connections and different type of services that can be applied for the connections set up, where the services can be such services as for example call waiting. The way these entities are functioning is further described in the document US-A-5 388 258, which document is herein incorporated by reference. The application and the ASU are preferably provided on at least one central hardware board comprising at least one processor with associated memories. The application and the ASU 12 are preferably provided in the form of one or more software modules written in a declarative programming language which in the preferred embodiment is Erlang, although other declarative programming languages can be contemplated. Erlang is described in the article "Erlang - A New Programming Language" by, B Dacker, Ericsson Review No. 2, 1993. The ARE 16 includes a system administration 18, three resource platforms 20, 22 and 24 and a system library 26. The three resource platforms 20, 22 and 24 are connected to the system administration 18 as well as to the system library 26. One first resource platform, resource platform 1 20, is shown connected to the open telecom platform 14 and connected to the ASU via a first interface 28 although in reality all resource platforms are connected to the ASU and the OTP in the same manner. The ASU 12 is also connected to the OTP 14. Also the system administration 18 is connected to the ASU 12 via said first interface 28. The OTP 14 is a toolbox used by the ARE, which OTP includes different tools and libraries for designing process control systems. The open telecom platform is based on the language Erlang and is described in more detail in the article "Open telecom platform" by S. Torstendahl, Ericsson Review No. 1 1997, which article is hereby incorporated by reference. It should be stressed that the open telecom platform is just a tool used for realizing the resource platforms and that they could be realized without this system. The first interface is a so called SPI (Service Provider Interface) and is preferably provided in the form of an Erlang module that is influenced by some of the functions mentioned in the S.300 specification from ECTF (Enterprise Computer Telephony Forum) . This interface is general for physical resources of different types delivered from different suppliers. An interface according to the S.300 specification is provided in the form of a function written in C or C++, which means that the SPI in the system according to the present invention is provided on a higher logical level. The system library 26 is a library used by all platforms and contains components used by all resource platforms, such as common protocols components, for instance for signaling over telecommunication lines. The application and ASU need also not be separate entities so that the ASU could just as well be provided in the application.

The way a certain platform is arranged will now be described in relation to fig. 2, which shows a block schematic of a first resource platform 20 connected to the ASU 12 and the different contents of this platform. In the figure the SPI has been omitted for the sake of clarity, but it would of course be provided between the resource platform and the ASU 12. The resource platform 20 comprises a platform handler 36, which communicates with the ASU 12 as well as with the system administration within the ARE (not shown) . The resource platform also comprises a resource control 29 and a resource interface 30, which both communicate with the platform handler as well as with a platform library 34. The resource control 29, the resource interface 30 and the platform library 34 all communicate with the OTP (not shown) . The resource interface 30 could be provided in the form of an Erlang module that handles communication between physical resources and the application together with appropriate drivers for driving hardware or other means for communication. It could be provided in the form of above mentioned ECTF S.300 interface or be implemented using socket communication. The resource interface is among other things used in order to provide the possibility for the application and the ARE, which are processes written in Erlang, to be able to communicate with other environments, for example environments written in the language C. It can however also be an Erlang module provided for communication with other Erlang modules provided on the physical resource. The resource control 29 also communicates with the ASU 12. The figure finally includes a physical resource 32 connected to the resource interface 30. The resource control 29 comprises resource modules of different types, which will be described in more detail later, and the platform library comprises functions that are common for these different resource modules. These functions are preferably also written in Erlang and can include driver support with common routines to be used when encoding/decoding data.

The application, the ASU and the OTP as well as all of the ARE except for the physical resource are preferably provided on one central hardware board comprising a processing unit and associated memory units. It is of course also possible to have them provided on different hardware boards or to provide the application and the ASU and OTP on one hardware board and the OTP and the ARE without physical resources on another hardware board. Other combinations can of course also be envisaged. Another possible variation is to provide the application, ASU, OTP, ARE and the physical resource on the same hardware board. A physical resource could, when the process control system is provided for control of a telephone exchange, be a hardware board comprising the switch core of the exchange and would then be of the type switch, a hardware board handling so called media resources such as tone generation, the media type, and a hardware board for handling so called network resources such as handling of physical links by signaling, the network type. The network type of resource is also called a primary resource, which is a resource controlled by the end user in a process control system. Such an end user can be a subscriber in a telephone network. The media and switch resource types are also called secondary resources, which are resources controlled by the application. In telecommunication the hardware board can also be another type of board having some or all of this functionality mentioned above. Such a different hardware board might be a so called switchboard which is a node connected in a ring network. Such a board is described in the Swedish patent application SE9604708-9, which is herein incorporated by reference. The switchboard is both part of a switch core as well as handles network and media resources for that part of the switch core. Another type of physical board can be a hardware board for a computer such as a PC.

The physical resource can also be provided as a distant independent resource, like a data base, that the process control system has access to but that is not any hardware board directly connected to and controlled by the application. An application only communicates with this physical resource for letting that resource perform an action of some sort. The physical resource would in the case of a data base have computational powers of its own and the ARE would only provide an interface for handling communication with this physical resource instead of actually handling some action to be performed on the resource. As mentioned earlier several resource modules might be included in a platform. In the same way several physical resources might be connected to the resource control 29.

The physical resource is normally connected to the central hardware board via a network of some kind irrespective of the type of physical resource and then normally via a local area network (LAN) .

One resource platform normally handles one type of switch hardware. For instance above mentioned media, switch and network hardware boards would be grouped together in one platform, while switchboards would be grouped in a separate platform. There might also exist one platform comprising physical resources common to above mentioned platforms, such a platform could then include common protocols, like for instance for signaling.

Fig. 3 shows a block schematic depicting three modules 38, 40 and 42 of different types arranged in one resource control 29 in the platform as well as the platform handler 36 and the system administrator 18, all of fig. 1. A first 38 of the resource modules, module 1, is of a type called the media type and handles so called media resources like tone generation, a second 40 of the resource modules, module 2, is of the switch type and handles the switch core of a telephone exchange and the third 42, module 3, is of the network type and handles the trunks and terminals connected to s switch core as well as signaling for such trunks. These modules are arranged for handling the resources of these types independently of where they are provided, i.e. independently of if a resource type is provided on a specific hardware board dedicated to the resource type or on a hardware board provided for several resource types. The modules are written in a declarative programming language, which in this embodiment is Erlang. The figure also shows a system server 44, a platform server 46 or register provided in the ASU 12. The ASU 12 also comprises the first interface 28, which is as stated earlier one or more modules written in Erlang. The system server 44 comprises for each platform a name for a platform, PL1, the name for at least one function in the platform, start-board. The register 46 comprises, for each resource module in a platform, functions fl, f2 and f3 with associated handles handlel, handle2, handle3. The platform handler 36 communicates with the system server 44 via the first interface 28 and the first resource module 38 communicates with the platform server 46 via the first interface 28. A specific physical resource 32 in the form of a hardware board is also shown connected to a second or resource interface 30. The second interface 30 is connected to the first resource module 38. The figure finally shows a broker 50 connected to the first 38 of the resource modules. A broker is a process written in Erlang that when it is called with a handle returns the identity of a certain process. The term process is well known within the world of Erlang, and Erlang and the structure of it is described in, for instance, the articles "Prototyping Cordless Using Declarative Programming", by I. Ahlberg, J-O. Bauner and A. Danne, Ericsson Review No. 2, 1993 which is herein incorporated by reference and above mentioned article "Erlang - A New Programming Language", by B Dacker, Ericsson Review No. 2 1993. The other resource modules would of course also be connected to physical resources and could also comprise brokers. In the figure only one platform server is shown, this platform server keeps track of all platforms and the resource modules in each platform. It is however possible to provide several platform servers, one for each platform.

Fig. 4 shows the content of the first module, which is as mentioned above, a module of the media type and has a name Medial, and includes a means 52 for registering the module or registrator and means fl, f2, f3 for handling actions to be performed on a physical board in the form of different functions included in the module. These functions are also called action handlers. The means for registering includes a registering function that can be activated by the platform handler as well as the name of all functions in the module and for at least one of the functions a handle associated with the function.

Fig. 5 shows a flow chart depicting a method of registering a resource in an application according a first embodiment the invention.

Fig. 6A and B show a flow chart depicting a method of registering a resource in an application according a second embodiment the invention. Now the method of registering a resource in an application according to the first embodiment will be described with reference to fig. 1, 2, 3, 4 and 5. In this first embodiment the resource type is above mentioned media type.

What happens first is, assuming that the system administration 18 has been started up in the ARE 16 and that the system server 44 and platform server 46 have been started up in the ASU, that the system administration 18 starts every platform 20, 22, 24 by starting the respective platform handler 36, procedural step 60. Since these different entities are in reality processes written in a declarative programming language, Erlang, a platform handler 36 is started by the system administration calling the module platform handler. Thereafter the platform handler 36 identifies the physical resources connected to the platform, procedural step 62. In the present case the hardware board 32 is a board of the media type. The resource module of the media type is thereafter initiated, procedural step 76. For media resources this is done by the platform handler calling a media module, which in turn connects to the resource interface 30. The resource interface checks the actual physical resources associated to itself and the types, i.e. which kind of hardware boards they are.

Through above mentioned identification the platform handler has been provided with a list of physical resources to be used for media resources. The platform handler then calls the first module 38 and starts it, whereafter the resource module registers itself in the platform server. Instead of the platform handler starting the resource module, the resource module could also have been started by a supervisor in the ARE, which supervisor would also be an Erlang module. This supervisor, also provided in the form of an Erlang module, would then start all resource modules.

In order to start the resource module medial 38, the platform handler comprises a function for calling the associated resource module. This function is first accessed, procedural step 64, which calling function thereafter requests registering of resource module in the platform server, procedural step 68. In the present case the first resource module 38 is thus asked to register itself in the platform server 46. The resource module therefore registers itself in the platform server using the name of the resource module, i.e. medial, the functions in the module together with possible handles associated with the functions, procedural step 70. The registering is of course carried out via the first interface 28. When the resource module registers itself, it registers its name, medial, the functions contained in the module, which functions are functions fl, f2 and f3 together with function handles handlel, handle2, handle3 associated with the functions. Not all functions might require handles.

The registering is performed in order for the application to be able to perform a certain action on or for the registered resource. An action on a resource can be such things as activating tone generation on the physical resource, while an action for a resource can be such a thing as setting up a connection to the physical hardware for sending a request and receiving an answer to that request from the physical resource. The action for a resource can also be the protocol conversion to be used for interfacing the application with a distant data base, which data base could perform some action such as gathering of certain information and returning it to the application. The registering is performed by the means for registering 52 or registering function supplied in the top of the module 38.

Thereafter all other resource modules are registered in the platform server 46.

Now the method of registering a resource in an application according to the second embodiment will be described with reference to fig. 1, 2, 3, 4, 6A and 6B. In this second embodiment the resource type is above mentioned network type.

What happens first is, assuming that the system administration 18 has been started up in the ARE 16 and that the system server 44 and platform server 46 have been started up in the ASU, that the system administration 18 starts a specific platform 20, 22, 24 by starting the respective platform handler 36, procedural step 72. Thereafter the platform handler 36 identifies the physical resources connected to the platform, procedural step 74.

For the sake of simplicity in describing the invention one resource module is here associated with one physical resource. When the platform handler 36 has identified the physical resources, it registers itself in the system server 44 via the SPI or first interface 28, procedural step 78. This registration is done through the platform handler sending its own name, the platform handler name PL1 together with at least one function per resource included in the platform handler that can be called by the application for starting a resource as well as the hardware position the resource is occupying. The functions in the platform handler that can be called are functions for associating resource modules to the application.

For the started platform 20, the platform handler 36 registers the platform name PL1, a function start-board, and the hardware position of the network board. Thereafter the application 10 accesses the system server 44 in the ASU 12 and requests system configuration, procedural step 80. This is done in order for the application to get knowledge of the resources which it has at its disposal in order to be able to run different processes in the resources. The system configuration is requested through the application calling the Erlang module system server. In response to this call the application receives above mentioned information about each platform, procedural step 82. The application then goes on to request start of the resource module by calling the platform handler 36 using the platform handler name, function start-board and the hardware position of the board where the network interface is provided, procedural step 84. The request is of course sent via the first interface 28.

As an alternative only the platform handler name could have been used for accessing a module. Then the platform handler would get in contact with a function calling a resource module through the use of a broker.

The platform handler thereafter accesses a function handling the network resource module, procedural step 86. Said function thereafter calls the associated network resource module and requests registering of the network resource module in the platform server, procedural step 88. The network resource module therefore registers itself in the platform server in the same way as the media resource did in the first embodiment, procedural step 90.

When a network resource is registered in the register, the name of a so called call-back function is registered in the network module by the application. This call-back function is to be called by the network module in case of a specific event. There are thus different call-back functions in the application for different events.

In the method described above in the first embodiment only one media resource was started in the platform. It is possible to start more than one resource module for the physical resources within a platform. Thus the platform server could contain several media modules and several network modules. When there are several such modules of one type in a platform and several harware boards of the media type there can exist a further Erlang module in the resource control. This module is an allocator which is registered in or for the application in the same way as the media module described in the first embodiment. This allocator is used to allocate a resource and therefore returns, when called, a chosen hardware board ant a resource within the board. The switch module is normally only one module though.

A switch module is furthermore registered in the same way as the media module described in the first embodiment of the invention.

An action on or for a switch resource comprises setting up or taking down a connection between a secondary resource and a primary resource, between two or more primary resources and between two secondary resources. An action on or for a media resource, for example sending a tone, comprises allocation of a media resource, by obtaining a media resource via above mentioned allocator as well as ordering the media board to start sending tones. In order for somebody to hear a tone the media resource does of course also have to be connected to a primary resource via the switch resource.

If the physical resource had been a so called switchboard, then a media module, a switch module, module 2, and a network module, module 3 would be started for the switchboard. In the case of a network comprising several switchboards interconnected by an optical ring as outlined in above mentioned Swedish application all three of these modules could be associated with several such switchboards .

The registration is performed in order to loosen the connection between the application and the actual hardware it is run on while at the same time taking the resource type into consideration. It is in other words performed in order to isolate an application run in a process control system from the physical resources used by that hardware. The big advantage of this arrangement is of course that the application and the ASU need not be changed when the process control system is to be run on new hardware. This makes the adaptation of the software in the process control system to the hardware it is to be run on easier and therefore large amounts of money can be saved from being spent on unnecessary software development, which development is only made for modifying an application to the software it is run on.

In order to exemplify how the bond between the application and the hardware is loosened, a short example will now be given of how the application can use a registered resource module.

The description will be made with reference made to fig. 1, 2, 3, 4 and 7, which latter figure shows a flow chart of a method of performing the action of tone generation on the resource module 38. First of all the application 10, when being run, receives information that a media function has to be performed. This is done through the network resource module receiving a certain event. This event could be information about a user of a telephone set lifting the phone off the hook. The event is forwarded to a function in the network resource module handling an appropriate call-back function. The function handling the call-back function calls the first interface using an event reporting function, where the name of the call-back function and the event is used as an argument. More arguments could of course also be included in the call. The event reporting function in the first interface thereafter calls the call-back function in the application, thereby reporting the event to the application. The application therefore decides that a tone has to be generated. The application 10 contacts the platform server 46 for obtaining information about correct resource module and function, procedural step 92. Thereafter the application calls function fl in the module medial 38 using the function handle handlel, procedural step 94. Thereafter the called function fl in the module medial starts running and in turn calls the broker 50 using handlel, procedural step 96. The broker returns a process identity obtained with the help of handlel to the function fl, procedural step 98. Thereafter the function fl accesses a part of the resource module medial, which handles a specific part of the physical resource 32, procedural step 100. This part of the module is arranged to order a specific part of the hardware to start generating a tone. In doing this the second interface is used to actually access the specific part of the hardware. The process identity returned by the broker is dependent of the physical resources used. A particular media hardware board has for instance one process identity and another media hardware board another process identity. In the case of a switchboard, i.e. a hardware board handling, switch, media and network resources, one process identity is provided for a specific board in all three types of resource modules.

The above given example was given in relation to a media board.

The same principles of accessing a certain part of a hardware board might be applied for a network board, for instance in the case of signaling. In the case of network boards and signaling there are different types of signaling that can be applied.

Different handles could here be used to point out different signaling schemes to be used on a telecommunication line. In the case of a hardware board that contains a switch core, handles do no have to be used when accessing a part of the board.

What was described above was deciding which part of a hardware board is to generate tones. Of course the generated tones will have to be supplied to a telecommunication line. This is done through connecting the part of the media hardware where the tone is generated to a part of the network board where the terminal is located. How such connection is done is something well known to the man skilled in the art and will therefore not be further described here.

In the case of a switchboard provided as a node in a network of nodes interconnected by optical fibre, several resource modules would access the same hardware board. In the same way some or part of the functions in a resource module could be provided on the hardware board so that the resource module would call an Erlang function on the physical board via the second interface. This could be achieved by using distributed Erlang when designing the function on the switchboard.

The ARE and each platform within it except for the physical resources can also be provided in the form of one or more computer program products or data carriers such as CD-ROMs or diskettes, which is operative after being loaded onto a hardware board.

The invention is of course not limited to the embodiments described above and shown in the drawings, but can be modified within the scope of the appended claims.

Claims

1. Method for obtaining isolation of at least one resource from an application (10) , which are both used in a process control system, where each resource comprises a physical resource (32) as well as at least one resource module (38, 40, 42) associated with one of at least two possible resource types, which resource module comprises at least one means (fl, f2, f3) for handling a specific action to be performed, by the application, on or for the resource and the resource is separated from the application, wherein the method comprises the steps of: registering each resource module with associated means for handling actions in a register (46) associated with the application (step 70; step 90), and calling from the application, when being run, a means (fl) for handling a specific action in a resource module (medial) for performing an action specialized for the resource type on or for the physical resource (32), (step 94).

2. Method according to claim 1, wherein the step of registering comprises registering at least one function (fl, f2, f3) together with a handle (handlel, handle2, handle3) .

3. Method according to claim 1 or 2, wherein several resources are grouped together in at least one resource platform (20, 22, 24) and comprising the further steps of: identifying the resources (38, 40, 42) belonging to at least one platform (20) from a platform handler (36) in the platform (step 74), requesting, from the application to the platform handler, start of at least one resource module of the platform (step 84), and performing said registering of a module in dependence of such a request.

4. Method according to claim 3, comprising the further steps of connecting all physical resources to be associated with a resource module to said resource module.

5. Method according to claim 3 or 4, comprising the further steps of: registering, by the platform handler (36), the started platform in a system server (44) to be used by the application (10) using a platform handler name (PL1) , (step 78), so that the application can obtain information about started platforms, requesting, by the application, configuration of the platform, through sending the platform name to the system server (step 80) and returning the platform handler name to the application by the system server (step 82) , wherein the step of requesting start of resource (step 84) includes sending the platform handler name from the application to the platform handler.

6. Method according to any previous claim, comprising the further steps of, when the application wants to perform a certain action on or for a physical resource: calling, from the application, a means for performing a specific action in a resource module using the module name, a name for said means for handling the action and a handle, (step 94), calling, from the means for handling the action, a broker using the handle, (step 96), returning, from the broker to the means for handling said action in the resource module, a process identity (step 98) , and accessing a specific part of a connected physical resource, identified with the aid of the process id, from the means for handling the action in the resource module (step 100) .

7. Method according to any previous claims, wherein the process control system is provided in a computer system.

8. Method according to claim 7, wherein the computer system is provided in a telecommunication switching system and the application is arranged for, among other things, controlling the setting up of traffic connections within the switching system.

9. Method according to any previous claim, wherein the application is provided on a first hardware entity comprising one or more hardware boards having central processing capability and a physical resource is provided in the form of at least one additional hardware board.

10. Method according to any previous claim, wherein all entities associated with the application, including the register, are provided in the first hardware entity.

11. Resource module (38) for registering at least part of a resource in an application (10) in a process control system, wherein the resource is one of at least two types and comprises said resource module as well as a physical resource and/or an interface to the physical resource, c h a r a c t e r i z e d in that the resource module is associated with one of the resource types and comprises: at least one means (fl, f2, f3) for handling a specific action to be performed, by the application, on or for the physical resource and means (52) for registering itself and associated means for handling actions, in a register (46) associated with the application, so that the application (28), when being run, can call a means (fl) for handling an action in the resource module (38) for performing an action specialized for the resource type on or for a physical resource (32) .

12. Resource module according to claim 10, wherein a means (fl) for handling an action in the resource module (38) , upon reception in the module of a call from the application using the module name (medial) , a name for the means for handling said action (fl) and a handle (handlel) registered in the register for said means for handling a specific action, when the application wants to perform a certain action on or for a physical resource (32), is arranged to call a broker (50) using the handle, and upon the returning from the broker of a process identity, is further arranged to access a specific part of a connected physical resource (32) identified with the aid of the process id so that the action can be performed on or for the physical resource.

13. Resource platform (20) arranged for registering at least one resource in an application in a process control system, where the resource is one of at least two types and comprises a physical resource (32) and/or an interface for accessing the physical resource together with at least one resource module associated with the resource type, c h a r a c t e r i z e d in that the resource module (38) is associated with one of the resource types and comprises: at least one means (fl, f2, f3) for handling a specific action to be performed, by the application, on or for the physical resource, and means (52) for registering itself and associated means for handling actions (fl, f2, f3) in a register (46) associated with the application, so that the application (10) , when being run, can call a means (fl) for handling an action in the resource module (38) for performing an action specialized for the resource type on or for a physical resource (32) .

14. Resource platform according to claim 13, wherein the platform (28) comprises a platform handler (36), in which each resource in the platform is registered, which platform handler comprises means for ordering a resource module (38) to register itself on or for the application (10) in dependence of a request for configuration of the platform received from the application.

15. Application resource system (16) in a process control system and being arranged for registering at least one resource in an application (10) , where the resource is one of at least two types, the application resource system comprising at least one resource platform (20, 22, 24), where each platform comprises at least one resource module (38, 40, 42) associated with the resource type as well as at least one physical resource (32) and/or an interface to such a physical resource, c h a r a c t e r i z e d in that each resource module is associated with one of the resource types and comprises: at least one means (fl, f2, f3) for handling a specific action to be performed, by the application, on or for the physical resource and means (52) for registering itself and associated means for handling actions in a register (46) associated with the application (10), so that the application, when being run, can call a means (fl) for handling an action in the resource module (38) for performing an action specialized for the resource type on or for a physical resource.

16. Process control system for loose coupling of resources to the system and comprising an application (10) to be run in the system, and at least one resource, which is one of at least two types and comprises a physical resource and/or an interface to such a physical resource, c h a r a c t e r i z e d in that the resource also comprises at least one resource module (38, 40, 42) associated with one of the resource types, the resource module comprising at least one means (fl, f2, f3) for handling a specific action to be performed, by the application (10) , on or for the physical resource, wherein the application (10) comprises or is associated with a register (46) and the resource module (38) comprises means (52) for registering itself and associated means for handling actions in the register, so that the application, when being run, can call a means (fl) for handling an action in the resource module for performing an action specialized for the resource type on or for a physical resource (32) .

17. Process control system according to claim 16, wherein several resources are grouped together in at least one resource platform (20, 22, 24), wherein each platform comprises a platform handler (36) for keeping track of started resources belonging to the platform, the application comprises means for requesting, from the platform handler, configuration of the platform, and the platform handler (36) comprises means for ordering a resource module to register itself in the application in dependence of such a request.

18. Process control system according to claim 17, wherein the platform handler (36) comprises means for registering the started platform in a system server (44) to be used by the application (10) using a platform name, so that the application can obtain information about started platforms, the application comprises means for requesting configuration of the platform, through sending the platform name to the system server and means for sending the platform handle to the platform handler after the return of the platform handle to the application by the system server, so that the resource module can register itself in the application.

19. Process control system according to any of claims 16 - 18, wherein: the application comprises means for calling a means (fl) for performing a specific action in a resource module (38) using the module name (medial), a name (fl) and a handle (handlel) for said means for handling the action, which handle has been registered together with said means for handling the action, the means for handling the action comprises means for calling a broker (50) using the handle and means for accessing, upon returning of a process identity from the broker, a specific part of a connected physical resource, identified with the aid of the process id, in order for the application to perform a certain action on or for said physical resource.

20. Process control system according to any of claims 16 - 19, wherein the process control system is provided in a computer system.

21. Process control system according to claim 20, wherein the computer system is provided in a telecommunication switching system and the application is arranged for, among other things, controlling the setting up of traffic connections within the switching system.

22. Process control system according to any of claims 16 - 21, wherein the application is provided on a first hardware entity comprising one or more hardware boards having central processing capability and a physical resource is provided in the form of at least one additional hardware board.

23. Process control system according to any of claims 16 - 22, wherein all entities associated with the application including the register, are provided in the first hardware entity.

24. Computer program product comprising: a computer usable storage medium having computer program code embodied in said medium for causing the assembly of sets of executable computer instructions which are part of a process control system to perform association of physical resources to the process control system, where the process control system comprises an application (10) and resources, where each resource is one of at least two types and comprises at least one physical resource (32) and/or and interface to said physical resource, said product having: means for organizing sets of executable computer instructions into at least one resource module (38, 40, 42) associated with one of the resource types, so that the resource module comprises at least one means (fl, f2, f3) for handling a specific action to be performed on or for the physical resource and means (52) for registering itself and associated means for handling actions in a register (46) associated with the application, so that the application, when being run, can call a means (fl) for handling an action in the resource module (38) for performing an action specialized for the resource type on or for a physical resource (32) .

25. Computer program product according to claim 24, wherein the computer program code is coded in a declarative programming language.

26. Method for obtaining isolation of at least one resource from an application, which are both used in a process control system, where each resource comprises a physical resource as well as at least one resource module associated with one of at least two possible resource types, which resource module comprises at least one action handler for handling a specific action to be performed, by the application, on or for the physical resource, wherein the method comprises the steps of: registering each resource module with associated action handler in a register associated with the application; and calling from the application, when being run, a specific action handler in a resource module for performing an action specialized for the resource type on or for the physical resource.

27. Resource module for registering at least part of a resource in an application in a process control system and the resource is one of at least two types and comprises said resource module as well as a physical resource and/or an interface to the physical resource; wherein the resource module is associated with one of the resource types and comprises: at least one action handler for handling a specific action to be performed, by the application, on or for the physical resource; and a registrator for registering itself and associated actions handlers in a register associated with the application, so that the application, when being run, can call an action handler in the resource module for performing an action specialized for the resource type on or for a physical resource.

28. Resource platform arranged for registering at least one resource in an application in a process control system, where the resource is one of at least two types and comprises a physical resource and/or an interface for accessing the physical resource together with at least one resource module associated with the resource type; wherein the resource module is associated with one of the resource types and comprises: at least one action handler for handling a specific action to be performed, by the application, on or for the physical resource; and a registrator for registering itself and associated actions handlers in a register associated with the application, so that the application, when being run, can call an action handler in the resource module for performing an action specialized for the resource type on or for a physical resource.

29. Application resource system in a process control system and being arranged for registering at least one resource in an application, where the resource is one of at least two types, the application resource system comprising at least one resource platform, where each platform comprises at least one resource module associated with the resource type as well as at least one physical resource and/or an interface to such a physical resource, wherein each resource module is associated with one of the resource types and comprises: at least one action handler for handling a specific action to be performed, by the application, on or for the physical resource; and a registrator for registering itself and associated actions handlers in a register associated with the application, so that the application, when being run, can call an action handler in the resource module for performing an action specialized for the resource type on or for a physical resource.

30. Process control system for loose coupling of resources to the system and comprising an application to be run in the system; and at least one resource, which is one of at least two types and comprises a physical resource and/or an interface to such a physical resource; wherein the resource also comprises at least one resource module associated with one of the resource types; the resource module comprising at least one action handler for handling a specific action to be performed, by the application, on or for the physical resource; wherein the application comprises or is associated with a register and the resource module comprises a registrator for registering itself and associated actions handlers in the register, so that the application, when being run, can call an action handler in the resource module for performing an action specialized for the resource type on or for a physical resource.

31. Computer program product comprising: a computer usable storage medium having computer program code embodied in said medium for causing the assembly of sets of executable computer instructions which are part of a process control system to perform association of physical resources to the process control system, where the process control system comprises an application and resources; where each resource is one of at least two types and comprises at least one physical resource and/or and interface to said physical resource, said product having: organizer for organizing sets of executable computer instructions into at least one resource module associated with one of the resource types, so that the resource module comprises: at least one action handler for handling a specific action to be performed, by the application, on or for the physical resource; and a registrator for registering itself and associated action handlers in a register associated with the application, so that the application, when being run, can call an action handler in the resource module for performing an action specialized for the resource type on or for a physical resource.