Controller engineering in networked environment

The term controller engineering represents since a long time not only local technical systems, existing of a combination of a control loop and operation sequences acting autonomous or partial-autonomous. Besides the manual input of information and commands e.g. a simple car-call, the communication between machines takes place more and more. As an example there is a solution found for a hospital with help of latest automation-components. This article shall exemplify how the system “Lift” becomes integrated into the superior system “Hospital” with its object-related regulations. The task formulation for the Amsterdam Medical Center (AMC) contained the integration of an access-system with transponder-cards for the reanimation-team, nursing stuff, security, and the technicians, who all of them have to share the resource “Lift” in the building. Furthermore controller-duties had to be mastered which demanded trans-sectoral networks and exceeded so the classical function of a standard lift by far.

Taking a look onto the flew of information inside of a lift-system there are beside the standard operation signal bus-systems are in use which are marked by predictable time-rating and clear access regulations. Basing on that the higher protocol-levels become implemented, which are realising different specific communication-versions, as the displayed producer-consumer-model (Fig.1) or the in Fig. 2 simplified server-client-model and so is for purpose prioritised. A typical example is the combination of the CAN-bus with CANopen as a standardised higher protocol- implementation with that the process-data-objects (PDO), service-data-objects (SDO) and features of the network-management (NMT) gets put into practice.

To grant the interaction of components from different make, basing on this an application profile (CANopen CiA 417) became established. This specifies the allocation of the information of the physically devices and the data objects. As such bus systems, working close to the controller components, are not really suitable to get connected to building-spanning networks due to their time-manner and the absolute determinism, another version, which can be parsed into several levels, provides a solution. For that at first a comprehensive display of the processes must get created, which contains all relevant data as position, state of operation, door- and shaft signals in terms of arguments. This gets updated autonomous by the controller in fixed time-intervals or event-oriented as on this example. Together with a set of access-methods for reading the variables and transmission of commands as “delete car-calls” or “set priority-call”, an interface gets established to that a system of higher level can access. In case of the hospital-solution for AMC an embedded-device-server (EPC) makes this job. This was fit into a box with top-hat-rails and so it was easy to integrate it into the control panel of a duplex lift. The displays of process of the single participant of the group become centrally registered by EPC via the common CAN-bus by means of CANopen and the application profile 417. This system, equipped with CAN- and Ethernet-link now is the interface for the building-network by priority use of TCP/IP. In the mentioned use case µC-Linux gets used as operating system in EPC and with that besides the TCP/IP-stack also other Unix-typical skills as multitasking and the support of common data-systems get used. As this is an industrial solution no hard disc and no active cooling became installed. Instead of that by consequently application of pure “embedded” components – flash storage and efficient micro controller – achieved a maximum of durability. The EPC now masters following assignments and delivers some of them in the network as a service to the outer world by TCP/IP.

• Implementation and application of the hospital specific card-regulation for the Reanimation team, the security, the nursing staff and the colleagues of the technique.
• Access to the display of process per DFÜ300-Stack, to use WinMOS^®300 Monitoring network-basing on the supervisory server-level.
• Local copies of the card-data-base (dispensed cards) to remain operable even on net-failure.
• Updating of the local card-data-base during active operation from the supervisory server-level, without interrupting the operation.
• Recording of long-term-information, e.g. the used cards during the day.

On this way each lift-group can work autonomously and remains operable even on failure of the building-spanning network. With the following step the next higher server-level was built which gathers the displays of process, being already supplemented by the client-specific card-data. During this process the data become statistical analysed. As the Ethernet is in use as a transmitting medium and by using of IP as a network-layer and TCP as transporting-layer shows no predictable time-manner, now no direct controller-jobs become realised. The connected WinMOS^®300 Server in truth has the task to collect fault- and maintenance-information, to store the latest process-displays, and to furnish the data for visualisation to the workstation-PCs (clients). Furthermore it receives the commands and transmits them to the next level below. The following figure is to illustrate that:

The workstation-PCs (Clients) furnish the following applications to the user:

• Suspend floors, give calls, remote on/off
• Activation of the special priority helicopter, which can get repositioned only by prepared cards or after expiration of an adjustable time of supply.
• Changing of special landings (case of fire, fire-fighting, emergency power supply)
• Access to the service-menu of each controller.
• Visualisation of car-position, speed, levelling and all relevant signals including the safety circuit.
• Display of the used transponder cards and further operating data.

The issued transponder cards are administrated in a MySQL-data base on server-level 2 and transmitted in data-form to level 1 (EPC in the machine room) of the duplex-lifts. This happens ether on users instruction at the workstation-PC (Client) or automatically with the reboot of an EPC. With that it is granted that all changes (e.g. type of cards, name of user/personal number and the mask of allocated lifts) become transmitted in one process and with that all EPCs are kept on the same current level. Besides the already mentioned MySQL-database also the WinMOS^®300 Monitoring-Server runs on the server-level 2 as NT-service and an Apache-Webserver which furnishes an extended Web-Front-End for the maintenance of the database to chosen clients. Apart from that the access to the cards-data happens by a Java-Server-Application on server-level 2, which then again gets its instructions from the Client-application of the workstation-PC. The Client-application offers dialogues fort he processing of prepared cards, type of cards, and allocated lifts. The following figure shows the surface for editing of card-data which becomes supplied to the user.

To configure new cards or to identify found cards the workstations (clients) are additional furnished  with a scanner. On each workstation-PC also runs WinMOS^®300 Monitoring, which receives all data from the server-level 2 and is responsible for the visualisation of the systems in operation. It gets supported from the Statistic-module to display times of call-waiting and stop-delay, door-motions as well as the Overview-module to display the systems and their operating-stands in the suitable position. So inter alia the operation in case of fire, emergency power supply, and fire-fighting. The access-protection to the system happens by user-name/password-authentication and IP address- lists. Within the WinMOS^®300-application user of the data-base and of Monitoring can become implemented to get different use-rights allocated.

In the practical conversion naturally also modifications on the control-program of the lift-systems are needed. Part of that is the implementing of special priorities, provision-times, and parameters. With it connected features can get adapted white real operating – in this specific example inter alia the provision-time of the helicopter-call.

The subdivision of the jobs to several levels enables the use of suitable bus-systems and components and also eases the distribution of the jobs within the team of developers. Absolute needed for that, are the exact interface-agreements and the use of standardised protocols, of which the development-efforts as of CANopen CiA 417 are carried by a community of interest. Also the naming and involving of responsible persons by the end customer is of enormous significance, as latest the server-level 2 becomes not more serviced by the maintenance-company but by the IT-department of the end customer. Preceding arrangements and agreements for administrative rights, features of the software to be developed, and providing of network inputs are to get started as early as possible. To give the customers the opportunity to check his defined cards- and special-regulations, in this current project they went a step ahead. On a model of a group of four lifts with simplified server-level 1 and 2 and two workstation-PCs (clients) together with the customer scenarios were gone through, and emerging conflicts of real-operating incidents were discussed and changes in documentation and implementation were done. All this before the transposition into practice which, as every body knows, always holds ready a bunch of vagaries.