Alexander Christiansen | Download | HTML Embed
  • Jul 12, 2002
  • Views: 16
  • Page(s): 6
  • Size: 1.10 MB
  • Report



1 ON-BOARD DATA MANAGEMENT STRUCTURE FOR ADVANCED CONSTRUCTION MACHINE SUPPORT by Jarosaw Jurasz1, Agata Ligier1, Alfons Horn2, Jochen Wendebaum1 ABSTRACT: A flexible on-board data management structure for a construction machine and interfaces between its elements are discussed. The solution, which grants the required flexibility and enables advanced, distributed functions is dis- cussed on the example of the road paving process. KEYWORDS: CANopen; digital work documentation; computer integrated road construction; road product model; site information systems; OPC; XML 1. INTRODUCTION The goal set by the authors is to design a flexible on-board data management structure Nowadays the construction machines are in- for a construction machine, equipped with creasingly often equipped with the on-board standardised interfaces. The article is structured computers, which support the operator and take as follows: after discussing the context and the over the control and documentation functions. requirements for the on-board structure the Their application is especially promising in contents of the information is investigated. civil engineering, where the machines perform Then the Osyris layered on-board structure is repeatable and well-defined tasks, e.g. laying, presented, followed by two examples of ad- compacting, grading. Thanks to advances in vanced, distributed functionality. positioning technology, on-board communica- tion and following the need of the users, who 2. CONTEXT wish to actively participate in the quality con- trol (Build-Own-Operate etc.), the on-board IT plays increasing role on the modern construc- tion site. Major part of the requirements set for the on- board IT is due to the need for applicability to different machines and worksites. This Figure 1. Heterogenous includes varying configuration structure of the road con- of positioning equipment, sensors struction site. and measurement systems coming from different providers. 1 Institute for Technology and Management in Con- With the increasing number and extending struction (TMB), University of Karlsruhe, Am Fa- functionality of CIRC systems in existence, the sanengarten, D-76128 Karlsruhe, Germany, tel. +49 problems of interoperability and standardisa- 721 608-3884, e-mail: {jurasz | ligier | wende- tion start to play a major role. Those topics are baum} addressed in the Osyris project, in the frame of 2 Moba Mobile Automation GmbH, Vor den Eichen which this work is carried out. 4, D-65604 Elz, Germany, tel. +49 6431 9577-132, e-mail: [email protected] 1

2 The major challenge for the Osyris on-board portant data categories managed on-board are data management structure is due to the hetero- (see Fig. 2.): geneous information structure of the worksite Design a description of a target road in a (see Fig. 1.), featuring: suitable digital form (what). Remains static Separate processes (e.g. earthmoving, lay- during the project execution. ing, re-profiling, transport), often per- Mission a description of the task to be formed by separate organisations, performed by a given machine (how). Re- Few standardised interfaces; GPS NMEA mains static for the given mission, changing standard3 is one notable exception, typically daily. Differently equipped machines coming Machine state consists of position, tool from different manufacturers, geometry and the process data, which vary Varying configuration (ad-hoc task alloca- in real-time. It can be used to derive the tion and team definition, add-on sensors, achieved work. different operating modes). Target machine state is a subset of ma- Clearly a separation is needed between the chine state subject to automatic control, de- managed process information and the details of rived from design, mission and current ma- the algorithm used to obtain or process it. To chine state, for example designed elevation assure flexibility and extensibility of the im- at the given point. plementation we propose to fix only data stor- Achieved work is a record of work execu- age structure and its interfaces. In this way the tion. It is gathered in real time and remains information can be accessed and/or provided static after the work execution. from any component without revealing the de- All the data categories listed above can be tails of how the information was acquired. As expressed as parameter values assigned to a the machines work in team, wireless real-time geometry, where design, tool or achieved ge- interfaces to the other machines have to be ometry can be used to carry the parameters. taken into account. Depending on the geometry they are assigned Nowadays 80..90% of the projects con- to, the same parameters can be used to specify ducted by European road contractors are vari- the actual or target values. The managed pa- ous maintenance tasks. The typical limited rameters can be outlined as follows: maintenance configuration (small paver and 1-2 Position: Geographic, Curvilinear coordi- small rollers) requires simple and cost-effective nates, linear and angular speed solutions. Inherent properties of the material: tem- perature and contents 3. INFORMATION CONTENTS Geometrical properties: thickness, even- The contents of the managed information is ness, volume, level deviation defined in the Osyris Functional Design. A Process and machine parameters: vibration, distinction between volatile real-time and static tampering, hydraulic pressure. information can be made here. The most im- Ambient conditions (temperature, wind, sunlight) Design Measurement & Machine state On-Board Office computer Clearly it is not possible to Control System computer Mission Target state Achieved define an exhaustive list of the work Mission parameters, so the definition of Worksite network Inputs Visualisation Guiding Inputs Queries Reports Analysis the additional parameters must be possible at the runtime. The On-Board computer Operator Manager identification of parameters can be performed using standardised Another machine names or codes. In any case it is very important to clearly define Figure 2. Functional decomposition of an OSYRIS system the meaning and units of the 3 Although many GPS receivers offer best perform- parameter values. ance using custom interfaces. 2

3 The piecewise-linear ribbon structure4 [1] ised components which provide advanced can be used to efficiently represent all data services (e.g. soft sensors). categories listed above. In the case of achieved The on-board system layers are presented in work description, the tool geometry with as- the Fig. 3. The abstraction level, amount of signed parameters describing state can be used managed data, and required performance de- as a ribbon generator. The ribbons introduce pend on the specialisation level: the natural ordering of the target parameter values along the road axis, so that extrapolation PMO responsible for permanent storage, mis- principle can be used to limit the number of sion preparation and work analyses [2]. managed parameter values. OB responsible for visualisation and storage It is important to note that multiple values of functions, best effort (not guaranteed) real one parameter may coexist at given time. For time behaviour. example the following values of machine speed MCS responsible for guaranteed real time need to be managed concurrently on-board: interfacing, filtering and control functions. measured by absolute positioning device, Multiple MCS devices are possible, al- e.g. GPS or Robotic Total Station though as of today an architecture with sin- measured by local positioning device, e.g. gle, central MCS is the most economical encoder solution. elaborated by data fusion algorithm, e.g. Kalman filter 4.1. CANopen interface specified as target for the mission. The Osyris CANopen interface approach is 4. LAYERED ON-BOARD STRUCTURE based on concept of a device profile, describing the measurement and control objects provided by the real time measurement and control sys- Product Model tems. The fast exchange of measured data be- PMO Office tween the MCS and the on-board computer is guaranteed by the efficient CANopen commu- XML interface nication layer (so called communication pro- Ribbon database file). The CANopen communication profile is already standardised. OPC interface OB Former approaches to the interfacing to the measurement and control systems on construc- OPC Server tion machines were based on lower level solu- tions (e.g. CAN) and, as the interface descrip- CANopen interface tion was hardcoded, changes in the system Measurement & Control System structure required a lot of modifications on (MCS) software and hardware level, which led to ad- ditional costs and less reliable systems. Custom low-level MCS Interfaces Therefore the Osyris solution promotes a Physical Layer standardised communication for construction (Sensors & Actuators) machines. As a part of the proposed solution the standard connector is also presented. The Figure 3. Osyris layered on-board structure advantages of standardised devices are numer- ous. It encourages the manufacturers to produce The Osyris system is based on components. standard measurement and control devices with In comparison with monolithic systems (e.g. their own technology hidden behind the stan- CIRC [3]) this approach enables easy recon- dard interface. figuration and provides framework for special- Furthermore the open solution allows con- tractors to use construction machines coming 4 The ribbon is created by moving a planar figure from different manufactures and connect them called generator along a curve called axis [1] 3

4 to one on-site management system, without any VB Application OPC Automation OPC Automation Local or Remote Interface Wrapper adaptations or modification in the MCS. OPC Server (Shared by many clients) The central part of the device profile is the C++ Application Server Data Cache object dictionary description (an extract is OPC Custom Interface shown in Table 1). The object dictionary is essentially a grouping of objects accessible via Physical Device/ CANopen in an ordered, predefined fashion. Data Each object within the dictionary is addressed Figure 4. OPC Architecture using a 16-bit index and 8-bit sub-index. The Object Dictionary contains only few mandatory OPC provides a snapshot of current machine items. They can be accessed according to the state as a hierarchy of named items together worksite requirements and a current configura- with the time stamp and quality information. tion. The MCS not only offers but also requires The items have standardised names and are items. The availability of items is resolved by mostly numeric values (vector and string are the on-board computer in runtime. also possible). The scaling between metric (SI) units and device units is performed by the Osy- Table 1. Extract of the paver device profile ris OPC Server. Index Object Description Osyris OPC namespace is divided in the 6000 Type of ma- Kind and type of machine following groups, mostly according to the ori- chine gin: 6010 MCS func- Indices of items supported by particular tionality implementation CanOpen machine state as received from 6020 Event General (start, stop etc) and machine- the MCS specific (vibration on/off etc) events 6100 Position The geographic position of machines CanOpenOut volatile target machine state tool in local coordinate system (E,N,H) (e.g. level deviation) elaborated by the on- 6101 Angle Posi- The attitude of the tool board computer, transmitted to the MCS tion 6102 Curvilinear The coordinates of the tool in the local Designed target state (e.g. thickness) as Co-ordinates curvilinear system defined in the mission 6103 Level Devia- The levelling error Pos machine position elaborated by the tion 6200 Thickness The thickness of the laid layer positioning component Manual parameter values may be over- 6300 Screed width The width of the screed and its exten- sions ridden manually by the operator 6310 Volume The volume of the laid material Default for many parameters, e.g. Tem- 6500 Material core The temperature of the laid material perature or Speed sensible default values temperature can be defined here, and used in case of 8010 MCS wish list Indices of items required by the MSC lack of sensors Process-specific groups, e.g. Material, CES 4.2. OPC layer (Compaction Expert System), CM (Cooling Model) The standardised interface to the actual ma- chine state parameters at the level of on-board In the Osyris implementation there is only computer is defined with help of the OPC. one Osyris OPC server, which allows reading OPC (OLE for Process Control) is a stan- and writing clients (no arbitration for writing is dardised set of interfaces, based on OLE/COM guaranteed at the OPC level). The Osyris im- and DCOM technology, for open software ap- plementation uses the OPC concept not only for plication interoperability between control ap- client-device communication, but additionally plications, field systems and devices, and busi- (which is an extension to the OPC standard) as ness/office applications [4]. Osyris uses a sub- a storage for the current machine state. Also set of OPC called Data Access. The data ex- clients which perform parameter estimation change is based on the server (provider)-client (soft sensors) can write into current state. (consumer) principle (see Fig. 4.). Writing to the device (in this case MCS) is allowed only in the CanOpenOut group. 4

5 In addition to the standard OPC, a concept Storage for cooling model and other algo- of the 'unqualified items' has been introduced. rithms As already mentioned, there can exist more Geometrical searching and iteration than one value for a parameter. If the client Parameter interpolation, e.g. elevation, component is interested in the best value, it thickness interpolation subscribes to the unqualified item (without Curvilinear transformation. specifying the group) and the server decides which one it is, based on the priority list and a - Road axis c - Road surface current qualities. (see Fig. 5.) connect to: Name Quality Speed Manual.Speed t2 tn t1 Pos.Speed return: CanOpen.Speed CanOpen.Speed Default.Speed ribbon nodes d - Machine path N ribbon vertices Figure 5. Example of Osyris OPC connec- ribbon nodes and vertices b- Road edge tion using an unqualified item name. diagonals Further extension of the OPC standard is the Figure 6. Sample ribbons in geographic coor- meta-information contained in the 'Events' dinates representing: a - road axis, b road OPC group. This concept is used to notify the edge, c road surface and d - machine path client that the best source of data has changed. In this way a fallback mechanism is imple- mented. 4.4. XML interfaces The OPC standard includes also a time- The interfaces between the on-board and the referenced interface to the past data, so called Office components are based on the XML stan- historical OPC. Unfortunately it cannot be em- dard. XML standard is wide spread in Internet ployed in the CIRC context, as space reference applications and many tools are available. A is missing. OPC can be also accessed remotely concept central to XML is the separation of the via DCOM. It is not used directly by the Osyris information contents and format. The informa- framework, but can be advantageous for de- tion contents of the geometry-based Osyris bugging, scripting or Web clients. XML files is based on ribbon concept. 4.3. Ribbon database At the beginning of work the on-board must be supplied with mission information (worksite As described in [1], ribbons (Fig. 6.) can be geometry, designed values of the work pa- used as a permanent storage for design, mission rameters like speed, fleet configuration). At the and achieved work. end of the work the achieved information has to be exported. There is also a request-response For each machine the tool geometry (de- schema, allowing the transfer of the current fined in mission or measured) is a machine work state at any time. The detailed schema has ribbon generator. There exist one dynamic rib- been defined for each exchange file format. bon for each machine, containing data gathered in real time (for more complex tool geometries 5. DISTRIBUTED OPERATION multiple ribbons are foreseen). The recorded position is represented by a ribbon diagonal, with the parameters assigned to it. 5.1. Wireless communication Ribbons provide following services: Wireless communication between machines Map visualisation of the parameters is based on a reliable multicast implemented upon Internet datagram (UDP) protocol. Typi- 5

6 cally WaveLANs are used as physical trans- laying can only be measured at the time of port. Ribbons with parameters are automati- paving on the paver, but the results of the core cally synchronised among the machines. This temperature calculation are most interesting for property can be used to implement distributed the compactor operator, giving him the very algorithms (see the following subchapters). valuable information about the time left to fin- ish the compaction (Fig. 7.). 5.2. Distributed pass counting 6. CONCLUSIONS One of the most valuable information con- cerning the quality of compaction comes from The presented on-board structure is univer- the pass counting. Given the past position of sal: all the relevant process parameters are rep- the compactor, the number of the done passes resented in uniform and coherent way and can can be calculated for each point of the surface, be transparently accessed on all the levels of resulting e.g. in a compaction coverage map. the system. Pre-existing standards have been On the most worksites at least two compactors used as a base for the Osyris interfaces. are working together. The coverage map is only The presented solution grants the required then useful if it contains passes from all the flexibility and enables advanced, distributed machines, and this is guaranteed by the wireless functions, for example distributed pass count- communication algorithm. ing and real-time simulation of the asphalt 5.3. Cooling model cooling (cooling model). Validation of the proposed framework on Another important parameter to take into the worksite is planned for Autumn 2002. The account during the asphalt laying is the tem- specifications of the interfaces will be pub- perature of the asphalt layer. Attempts to meas- lished at the end of the project. ure the surface temperature of the asphalt at the compactor using infrared sensors are unreliable Acknowledgements due to the high influence of the wind speed on the surface temperature. The work described in the paper was carried out in the framework of the European Project OSYRIS: Open System for Road Information CANopen Sensors Paver Support (Growth No. GRD1-1999-10815), 2000-2003 [5]. OPC Server Calculation 7. REFERENCES Ribbon DB [1] J. Jurasz, Universal digital environment model for computer integrated road con- Wireless struction. Proc. 18th ISARC 31-36, Cracow Transmission 2001 [2] A. Ligier, J. Fliedner, J. Kajanen, F. Peyret, Open System For Road Information Sup- Ribbon DB Presentation port. Proc. 18th ISARC, Cracow 2001 OPC Sever Compactor [3] F. Peyret, J. Jurasz, A. Carrel, E. Zekri, B. Gorham: The Computer Integrated Road Construction project, Automation in Con- Figure 7. Cooling model as an example of a struction 9 (5-6) (2000) pp. 447-461. distributed application in the OSYRIS system [4] OPC Foundation at To calculate the evolution of the tempera- ture inside an asphalt layer, a mathematical model has been used. The model parameters [5] Osyris Website at http:// like layer thickness and asphalt temperature at 6

Load More