Monitoring - controlling system for appliances mounted on mobile vehicles

Description

[0001] DESCRIPTION Nowadays the use of mobile vehicles in executing specific tasks is common and consolidated practice. Examples are trucks operating garbage collection in residential areas and vehicles fitted with tanks and containers to carry specific materials and for intervention (liquid sewage, mud and water discharge transport, fire brigade tanker, etc...). In similar situations the devices dedicated to specific tasks are mounted onto the truck structure, maintaining their own independence; the vehicle allows the operation of these devices and, if necessary, it provides the mechanical power (through the drive shaft connected to the engine) and the electrical power supply (batteries and energy generation system). Operating the mobile vehicle is therefore independent from operating the carried devices: truck constructors provide at most some signals characterising the vehicle working conditions, thus allowing the measurement and monitoring of relevant quantities, also for safety issues. The user may have access (often under request and through re-programming of the electronic control devices) to signals such as:

• vehicle running;
• neutral gear;
• stationary brake;
• mechanical drive shaft connected to the engine;
• engine rotation.

[0002] Truck service companies (for examples garages, setting-up companies, etc...) install either on tractors and on trailers the requested devices. Such equipments include components that are part of the following categories:

• sensors (such as mechanical transducers, for both angular and linear movements, proximity, level, temperature, and electrical quantities measurement)
• actuators (such as oleodynamic and pneumatic electrovalves, mechanical releasers, relais commands, signalling lamps, etc...)

[0003] it's the operator duty to drive the actuators and to get informations from the sensors, also by means of automatic (or semi-automatic) control devices supporting the operator in totally or partially executing the requested tasks.

[0004] This patent presents a system, developed for monitoring and control of industrial devices mounted on mobile vehicles, having the following characteristics:

1) The control procedures and the data analysis are executed using on a traditional computing device (a personal computer, PC).

2) It interfaces to the sensors and actuators through a fieldbus.

3) It requires a user interaction through an operator interface managed by the computer.

4) It bases the control procedures on custom software developed using high level programming language.

[0005] Therefore the system integrates hardware technologies and software solutions that are either already available from vendors (such as the hardware for interconnection and data processing), or custom designed and programmed (such as the control and monitoring algorithms).

Computation unit.

[0006] The proposed system is based on a Personal Computer (PC) as computation unit for collecting informations and for the management of the user interaction. The term "PC" refers also to Personal Computers designed for operations in industrial environment (usually called "Industrial PC"). The presented system utilises such products, often provided with LCD screens and prepared for easy integration in industrial automation environments. From a functional point of view, office PCs can be also utilised (with computational power adequate to software requirements), if reliability issues and occupied space suggest not to rely on them. Industrial devices called Programmable Logic Controllers (PLCs) are not considered, even if they are traditionally employed in this field; towards them the presented system claims advantages in terms of configurability and ease of maintenance and programming.

[0007] The computing platform is based on standard operating systems for the execution of the monitoring and control software. Standard operating systems are the ones that are commercially or freely available (such as Microsoft's ones or based on Unix and Linux platforms), or are derived from them, even structured with a reduced number of "modules" (functionalities). The operating systems considered in the proposed system can have also additional "modules" to improve computational performances (such as kernel patches and/or process scheduling in order to get hard or soft real-time performance).

Interconnection system.

[0008] The proposed system includes a fieldbus-based interconnection network for the interface to sensors and actuators. With regard to industrial devices installed on mobile vehicles, the fieldbus has the same role as in industrial environments or in factories even if the reduced physical extension of the installation limits somehow the network specifications to be consider in the data transfer (from the field to the control unit). Actually the installed interconnection network is not structured according to hierarchical layers, with different fieldbus levels: the only fieldbus must guarantee the transmission requirements, the timing constraints and the communication reliability necessary to the system control. As examples, suitable fieldbus for the proposed system are CAN (also implemented as CANopen) and AS-I.

[0009] The main advantages of the fieldbus transmission system are:

1) Reduced cabling. Sensors and actuators are connected to the nearest fieldbus device (also acting as interface), or directly to the bus (in case they have internally the interface), instead of having their own electrical terminals wired directly to the computation unit. In this configuration the cabling space can be highly reduced, with shorter installation and testing time. The very few electrical wires for data transfer are the bus cables: furthermore it is not required a predefined interconnection order (sequence) for the devices as data messages (packets) are managed exclusively according to the addressing implemented in the fieldbus protocol.

2) Installation testing. The actual interconnection must be guaranteed for few wires (typically two): the whole communication procedure is governed by software as long as the physical link is available. Thanks to this approach, it is simpler to point out problematic connections and to identify faulty devices.

3) Fieldbus selection. The designed system is not restricted to the use of a single fieldbus as it can take advantage of any structure suitable to transfer data. The only requirement is the existence of a device (often with "master" capabilities) through which the software can manage and control all the connected devices (sensors and actuators).

User operating interface.

[0010] The user that operates the system mounted on the mobile vehicle may interact with the devices and manages the operations using a graphical interface on a standard video output. Standard video output is a CRT (Cathod Ray Tube) or a LCD (Liquid Crystal Display) screen (monitor) that is usually connected to the output of a common PC video board, usually through a VGA or DVI connector. Therefore customised operator panels (for example dot-matrix and segments display) are not included into this category. An optional "Touch Screen" device can be integrated into the screen or it can be subsequently added as optional component for a direct interaction with the displayed interface elements (for example buttons and controls). Moreover physical buttons integrated in the monitor structure could be expected if they make easier the user interaction when they are managed by the PC (through appropriate software driver) as a keyboard or as a restricted set of keys (such as the keyboard function keys).

Monitoring and control software.

[0011] The software used in the system is developed on purpose for such applications (monitoring and control of industrial devices on mobile vehicles). It is written using high level programming language (such as C++, Delphi, etc...), also structured in modules (libraries), and it relies on the PC operating system and on the peripheral software drivers. It is developed independently from existing programs that manage industrial devices (such as "Human Machine Interface" (HMI) applications) and it is not based on programming languages specifically employed in coding control algorithms (such as in IEC 61131-3 standard).

[0012] Data acquisition and command delivering is performed through a device connected to the fieldbus, in order to provide an interface towards sensors and actuators installed on the system: this is usually achieved using a "master" device either integrated on the PC (as an additional board installed on a PCI slot), or external (interconnected to the PC by means of traditional communication links such as Ethernet, serial port, parallel port, ...).

[0013] The software is an executable program. It is structured in modules in order to help the programming and the management of the various procedures.

[0014] Three main modules can be considered, with the following functionalities:

• implementation of the operating procedures for control and system configuration;
• fieldbus management;
• user interface management.

[0015] Hereafter they are described in details.

1. Module implementing the operating control procedures and the system configuration.

[0016] In this module the controller performs the following tasks:

• It detects sensors and actuators, it recognises and matches their capabilities to the operating functionalities of the industrial vehicle. In this phase it resolves every addressing issue related to the communication through the fieldbus and it identifies every device task (for example it relates a movement limit to its corresponding sensor, an electric valve to an actuator, etc...). Furthermore a check is performed in order to validate the actual configuration according to the required operating condition. If faults are detected, not allowing the safe execution of every system functionalities (such as the lack of detection in the reach of a mechanical limit), the software enters a "user warning mode" thus allowing the problem identification and solving.
• It details the control algorithms with specific values to be used in running mode. This step sets the execution timing when they are applicable (such as actuators activation time and/or waiting time between operations) and it defines the operating conditions that change the control procedures (as example exceeding defined linear or angular mechanical movements). Those values permit the system operation under various operating conditions using different control algorithms: it is the case when commands are delivered for a length of time (defined by those time values) or until a certain event occurs (for example until a defined sensor detects a signal with a defined value).
• It implements the procedures the system must execute upon operator command (through the graphic interface and/or the command buttons) or if sensors detect a predefined system state. Such procedures consist of single instruction sequences that are performed according to timings and steps defined by the programmed control logic, by the implemented set of parameters and by the detected system state. Error checking is always considered in the control algorithms (and countermeasures are consequently taken) when the system is expected to reach a defined state and this doesn't occur after a predefined time (timeout condition). For example this happens when an actuator drives a mechanical movement and the corresponding end position is not detected after a reasonable time period. The control logic is implemented according to the functional behaviour required by the system.
• It monitors every safety condition that depends both on the industrial devices and on the vehicle they are mounted on. This includes the checking on the signals generated by the vehicle (e.g. moving vehicle, neutral gear position, stationary brake inserted, mechanical drive actuated, etc...).
• It manages the information acquired by the fieldbus and commanded by the user through the graphical interface (for example the routines for data acquisition and the commands to start the various control algorithms).

2. Module implementing the fieldbus management.

[0017] This module performs the following tasks:

• It manages the software interface together with the operating system driver, allowing data retrieval and command delivering through the fieldbus. If the fieldbus interface (usually the master device) is a PC plug-in board, the driver is specific to that board; on the other hand, if the fieldbus interface is external (for example if the master device is connected through LAN or serial port), the software includes the specific communication protocol stack (in the above examples, the TCP/IP or UDP socket or the serial data transmission).
• It delivers basic I/O functions to read the sensors status and to deliver commands to the actuators. This provides complete software functions wrapped around the basic features of the driver routines. These functions give the possibility to the control algorithms to call full-featured algorithms that include also error-checking capabilities (with possible remedial actions to be undertaken). Therefore the software is independent from the physical fieldbus interface giving the possibility to be easily modified if the actual interface changes. The code changes only in the function routines: the control software remains unchanged as the function prototypes are independent from the physical interface (this happens not only when the fieldbus board is replaced but also if the fieldbus itself is changed).
• It gives the possibility to access the fieldbus (retrieving data and/or sending commands) independently from the corresponding function calls in the control software. For example this allows more than one control process to access the fieldbus through the same master device, provided that the different processes act on different sets of slave devices (otherwise contention errors may occur). In the same way a master device can be considered if it provides multiple interfaces towards the fieldbus, and each interface is connected to a different (sub)network: the software permits simultaneous action on the different networks as they are logically kept distinguished by the I/O functions.

3. Module implementing the user interface.

[0018] This module performs the following tasks:

• It manages the user interaction through the industrial PC display, it provides the system status information and it permits the commands execution for the system control procedures. The display of the system status can be highly effective on the screen if the presented data is organised in graphic form, thus allowing a fast and easy way to recognise the configuration of the installed devices: this can be done using icons, lighting effects, bar meters, etc...
• It activates warning video alarms when anomalous running conditions are detected and when unaccepted system configurations are set.
• It helps the initial setup of the control program, the insertion of the operating parameters and the checking on the action executed (e.g. using graphical views, log files, etc...).
• It provides online help for a fast understanding of the functionalities the operator can use.

[0019] The software, organised in the described modules, is designed to fully exploit the high-level programming language features and, at the same time, to get benefits from all the functionalities embedded in the considered operating systems. In particular, the accurate algorithm design allows the implementation of concurrent control processes (multithread programming). This helps the execution of self-contained routines (independent from one another): for example it is possible to verify the device status and to drive actuators meanwhile the control algorithm manages the system. Other than under operating conditions, this is also useful during system maintenance where it helps in the detection of erroneous events.

[0020] The software, keeping track of every action undertaken during its execution, allows a complete monitoring (also in a "log file") of the system "history". This is essential when it is required to evaluate a particular functional behaviour after the event occurred, in order to identify (and, if it is the case, to correct) what happened. As the recorded history is managed in cyclic behaviour, (overwriting older log files), a trade-off can be obtained between the availability of the complete system history in a defined time period without incurring in unnecessarily overloading the PC memory storage capability.

Claims

1. Monitoring - controlling system for appliances mounted on a mobile vehicle, composed by:

- a central processing unit (Personal Computer based) that executes the monitoring and controlling procedures;

- an interface for fieldbus interconnection;

- one or more devices (peripheral devices) that: 1) sense the working conditions of the appliances mounted on the vehicle, or 2) execute commands on the appliances;
characterised in that:

- the central processing unit is based on a traditional computing device (a personal computer, PC);

- the software that performs the monitoring - controlling procedures is specifically programmed using high level programming language;

- the communication between the central processing unit and the peripheral devices is based on a fieldbus interconnection;

- the computing platform is based on standard operating systems for the execution of the monitoring and control software.

2. Monitoring - controlling system according to claim 1, characterised in that the central processing unit is a strengthened version of hardware with the same functionalities (or even a subset) of the ones present in a Personal Computer. Such devices are often called Industrial PCs as they can withstand the operating conditions in harsh environments, like the ones in industrial plants.

3. Monitoring - controlling system according to claim 1, characterised in that it can exchange information (in both ways) with the system that manages the mobile vehicle (without considering the installed appliances). This doesn't represent a control on the mobile vehicle as it is performed only: 1) when safety issues arise, or 2) when the working behaviour of the installed appliances depends on the working conditions of the mobile vehicle.

4. Monitoring - controlling system according to claim 1, characterised in that the operator of the appliances installed on the mobile vehicle can execute specific tasks through a human machine interface (such as using a video monitor, eventually provided with touch screen and/or buttons and/or keyboards) that is managed by the same central processing unit that runs the monitoring and controlling procedures.

5. Monitoring - controlling system according to claim 1, characterised in that the operating systems can have also additional "modules" to improve computational performances (such as kernel patches and/or process scheduling in order to get hard or soft real-time performance).

6. Monitoring - controlling system according to claim 1, characterised in that the software, keeping track of every action undertaken during its execution, allows a complete monitoring (also in a "log file") of the system "history".