1

ON-BOARD DATA MANAGEMENT STRUCTUREFOR ADVANCED CONSTRUCTION MACHINE SUPPORT

by

Jarosław Jurasz1, Agata Ligier1, Alfons Horn2, Jochen Wendebaum1

ABSTRACT: A flexible on-board data management structure for a constructionmachine and interfaces between its elements are discussed. The solution, whichgrants 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 roadconstruction; road product model; site information systems; OPC; XML

1. INTRODUCTION

Nowadays the construction machines are in-creasingly often equipped with the on-boardcomputers, which support the operator and takeover the control and documentation functions.Their application is especially promising incivil engineering, where the machines performrepeatable and well-defined tasks, e.g. laying,compacting, grading. Thanks to advances inpositioning technology, on-board communica-tion and following the need of the users, whowish to actively participate in the quality con-trol (Build-Own-Operate etc.), the on-board ITplays increasing role on the modern construc-tion site.

Major part of therequirements set for the on-board IT is due to the needfor applicability to differentmachines and worksites. Thisincludes varying configurationof positioning equipment, sensorsand measurement systems comingfrom different providers.

With the increasing number and extendingfunctionality of CIRC systems in existence, theproblems of interoperability and standardisa-tion start to play a major role. Those topics areaddressed in the Osyris project, in the frame ofwhich this work is carried out.

The goal set by the authors is to design aflexible on-board data management structurefor a construction machine, equipped withstandardised interfaces. The article is structuredas follows: after discussing the context and therequirements for the on-board structure thecontents of the information is investigated.Then the Osyris layered on-board structure ispresented, followed by two examples of ad-vanced, distributed functionality.

2. CONTEXT

1 Institute for Technology and Management in Con-struction (TMB), University of Karlsruhe, Am Fa-sanengarten, D-76128 Karlsruhe, Germany, tel. +49721 608-3884, e-mail: {jurasz | ligier | wende-baum}@tmb.uka.de2 Moba Mobile Automation GmbH, Vor den Eichen4, D-65604 Elz, Germany, tel. +49 6431 9577-132,e-mail: horn@moba.de

Figure 1. Heterogenousstructure of the road con-struction site.

2

The major challenge for the Osyris on-boarddata management structure is due to the hetero-geneous information structure of the worksite(see Fig. 1.), featuring:

� Separate processes (e.g. earthmoving, lay-ing, re-profiling, transport), often per-formed by separate organisations,

� Few standardised interfaces; GPS NMEAstandard3 is one notable exception,

� Differently equipped machines comingfrom different manufacturers,

� Varying configuration (ad-hoc task alloca-tion and team definition, add-on sensors,different operating modes).

Clearly a separation is needed between themanaged process information and the details ofthe algorithm used to obtain or process it. Toassure flexibility and extensibility of the im-plementation we propose to fix only data stor-age structure and its interfaces. In this way theinformation can be accessed and/or providedfrom any component without revealing the de-tails of how the information was acquired. Asthe machines work in team, wireless real-timeinterfaces to the other machines have to betaken into account.

Nowadays 80..90% of the projects con-ducted by European road contractors are vari-ous maintenance tasks. The typical limitedmaintenance configuration (small paver and 1-2small rollers) requires simple and cost-effectivesolutions.

3. INFORMATION CONTENTS

The contents of the managed information isdefined in the Osyris Functional Design. Adistinction between volatile real-time and staticinformation can be made here. The most im-

3 Although many GPS receivers offer best perform-ance using custom interfaces.

portant data categories managed on-board are(see Fig. 2.):

� Design – a description of a target road in asuitable digital form (what). Remains staticduring the project execution.

� Mission – a description of the task to beperformed by a given machine (how). Re-mains static for the given mission, changingtypically daily.

� Machine state consists of position, toolgeometry and the process data, which varyin real-time. It can be used to derive theachieved work.

� Target machine state is a subset of ma-chine state subject to automatic control, de-rived from design, mission and current ma-chine state, for example designed elevationat the given point.

� Achieved work is a record of work execu-tion. It is gathered in real time and remainsstatic after the work execution.

All the data categories listed above can beexpressed as parameter values assigned to ageometry, where design, tool or achieved ge-ometry can be used to carry the parameters.Depending on the geometry they are assignedto, the same parameters can be used to specifythe actual or target values. The managed pa-rameters can be outlined as follows:

� Position: Geographic, Curvilinear coordi-nates, linear and angular speed

� Inherent properties of the material: tem-perature and contents

� Geometrical properties: thickness, even-ness, volume, level deviation

� Process and machine parameters: vibration,tampering, hydraulic pressure.

� Ambient conditions (temperature, wind,sunlight)

Clearly it is not possible todefine an exhaustive list of theparameters, so the definition ofthe additional parameters mustbe possible at the runtime. Theidentification of parameters canbe performed using standardisednames or codes. In any case it isvery important to clearly definethe meaning and units of theparameter values.

On-Boardcomputer

Achievedwork

DesignMachinestate

Operator

Measurement &Control System

Target state

Worksitenetwork

Another machine

On-Boardcomputer

Office computerMission

Inputs

Manager

MissionInputs

QueriesVisualisationGuiding

ReportsAnalysis

Figure 2. Functional decomposition of an OSYRIS system

3

The piecewise-linear ribbon structure4 [1]can be used to efficiently represent all datacategories listed above. In the case of achievedwork description, the tool geometry with as-signed parameters describing state can be usedas a ribbon generator. The ribbons introducethe natural ordering of the target parametervalues along the road axis, so that extrapolationprinciple can be used to limit the number ofmanaged parameter values.

It is important to note that multiple values ofone parameter may coexist at given time. Forexample the following values of machine speedneed to be managed concurrently on-board:

� measured by absolute positioning device,e.g. GPS or Robotic Total Station

� measured by local positioning device, e.g.encoder

� elaborated by data fusion algorithm, e.g.Kalman filter

� specified as target for the mission.

4. LAYERED ON-BOARD STRUCTURE

Physical Layer(Sensors &Actuators)

Custom low-levelInterfaces

Measurement &Control System

(MCS)

CANopen interface

OPC Server

OPC interface

Ribbon database

XML interface

Product ModelOffice

PMO

MCS

OB

Figure 3. Osyris layered on-board structure

The Osyris system is based on components.In comparison with monolithic systems (e.g.CIRC [3]) this approach enables easy recon-figuration and provides framework for special-

4 The ribbon is created by moving a planar figurecalled generator along a curve called axis [1]

ised components which provide advancedservices (e.g. soft sensors).

The on-board system layers are presented inthe Fig. 3. The abstraction level, amount ofmanaged data, and required performance de-pend on the specialisation level:

PMO – responsible for permanent storage, mis-sion preparation and work analyses [2].

OB – responsible for visualisation and storagefunctions, best effort (not guaranteed) realtime behaviour.

MCS – responsible for guaranteed real timeinterfacing, filtering and control functions.Multiple MCS devices are possible, al-though as of today an architecture with sin-gle, central MCS is the most economicalsolution.

4.1. CANopen interface

The Osyris CANopen interface approach isbased on concept of a device profile, describingthe measurement and control objects providedby the real time measurement and control sys-tems. The fast exchange of measured data be-tween the MCS and the on-board computer isguaranteed by the efficient CANopen commu-nication layer (so called communication pro-file). The CANopen communication profile isalready standardised.

Former approaches to the interfacing to themeasurement and control systems on construc-tion machines were based on lower level solu-tions (e.g. CAN) and, as the interface descrip-tion was hardcoded, changes in the systemstructure required a lot of modifications onsoftware and hardware level, which led to ad-ditional costs and less reliable systems.

Therefore the Osyris solution promotes astandardised communication for constructionmachines. As a part of the proposed solutionthe standard connector is also presented. Theadvantages of standardised devices are numer-ous. It encourages the manufacturers to producestandard measurement and control devices withtheir own technology hidden behind the stan-dard interface.

Furthermore the open solution allows con-tractors to use construction machines comingfrom different manufactures and connect them

4

to one on-site management system, without anyadaptations or modification in the MCS.

The central part of the device profile is theobject dictionary description (an extract isshown in Table 1). The object dictionary isessentially a grouping of objects accessible viaCANopen in an ordered, predefined fashion.Each object within the dictionary is addressedusing a 16-bit index and 8-bit sub-index. TheObject Dictionary contains only few mandatoryitems. They can be accessed according to theworksite requirements and a current configura-tion. The MCS not only offers but also requiresitems. The availability of items is resolved bythe on-board computer in runtime.

Table 1. Extract of the paver device profile

Index Object Description6000 Type of ma-

chineKind and type of machine

6010 MCS func-tionality

Indices of items supported by particularimplementation

6020 Event General (start, stop etc) and machine-specific (vibration on/off etc) events

6100 Position The geographic position of machine’stool in local coordinate system (E,N,H)

6101 Angle Posi-tion

The attitude of the tool

6102 CurvilinearCo-ordinates

The coordinates of the tool in the localcurvilinear system

6103 Level Devia-tion

The levelling error

6200 Thickness The thickness of the laid layer

6300 Screed width The width of the screed and its exten-sions

6310 Volume The volume of the laid material

6500 Material coretemperature

The temperature of the laid material

8010 MCS wish list Indices of items required by the MSC

4.2. OPC layer

The standardised interface to the actual ma-chine state parameters at the level of on-boardcomputer is defined with help of the OPC.

OPC (OLE for Process Control) is a stan-dardised set of interfaces, based on OLE/COMand DCOM technology, for open software ap-plication interoperability between control ap-plications, field systems and devices, and busi-ness/office applications [4]. Osyris uses a sub-set of OPC called Data Access. The data ex-change is based on the server (provider)-client(consumer) principle (see Fig. 4.).

OPC Automation

Interface

OPC Custom Interface

Local or RemoteOPC Server

(Shared by many clients)

Server Data Cache

PhysicalDevice/

Data

OPC AutomationWrapper

VBApplication

C++Application

Figure 4. OPC Architecture

OPC provides a snapshot of current machinestate as a hierarchy of named items togetherwith the time stamp and quality information.The items have standardised names and aremostly numeric values (vector and string arealso possible). The scaling between metric (SI)units and device units is performed by the Osy-ris OPC Server.

Osyris OPC namespace is divided in thefollowing groups, mostly according to the ori-gin:

� CanOpen – machine state as received fromthe MCS

� CanOpenOut – volatile target machine state(e.g. level deviation) elaborated by the on-board computer, transmitted to the MCS

� Designed – target state (e.g. thickness) asdefined in the mission

� Pos – machine position elaborated by thepositioning component

� Manual – parameter values may be over-ridden manually by the operator

� Default – for many parameters, e.g. Tem-perature or Speed sensible default valuescan be defined here, and used in case oflack of sensors

� Process-specific groups, e.g. Material, CES(Compaction Expert System), CM (CoolingModel)

In the Osyris implementation there is onlyone Osyris OPC server, which allows readingand writing clients (no arbitration for writing isguaranteed at the OPC level). The Osyris im-plementation uses the OPC concept not only forclient-device communication, but additionally(which is an extension to the OPC standard) asa storage for the current machine state. Alsoclients which perform parameter estimation(soft sensors) can write into current state.Writing to the device (in this case MCS) isallowed only in the CanOpenOut group.

5

In addition to the standard OPC, a conceptof the 'unqualified items' has been introduced.As already mentioned, there can exist morethan one value for a parameter. If the clientcomponent is interested in the ‘best’ value, itsubscribes to the unqualified item (withoutspecifying the group) and the server decideswhich one it is, based on the priority list andcurrent qualities. (see Fig. 5.)

Manual.SpeedSpeed

Pos.Speed

CanOpen.Speed

CanOpen.Speed Default.Speed

connect to:

return:

Name Quality

Figure 5. Example of Osyris OPC connec-tion using an unqualified item name.

Further extension of the OPC standard is themeta-information contained in the 'Events'OPC group. This concept is used to notify theclient that the best source of data has changed.In this way a fallback mechanism is imple-mented.

The OPC standard includes also a time-referenced interface to the past data, so calledhistorical OPC. Unfortunately it cannot be em-ployed in the CIRC context, as space referenceis missing. OPC can be also accessed remotelyvia DCOM. It is not used directly by the Osyrisframework, but can be advantageous for de-bugging, scripting or Web clients.

4.3. Ribbon database

As described in [1], ribbons (Fig. 6.) can beused as a permanent storage for design, missionand achieved work.

For each machine the tool geometry (de-fined in mission or measured) is a machineribbon generator. There exist one dynamic rib-bon for each machine, containing data gatheredin real time (for more complex tool geometriesmultiple ribbons are foreseen). The recordedposition is represented by a ribbon diagonal,with the parameters assigned to it.

Ribbons provide following services:� Map visualisation of the parameters

� Storage for cooling model and other algo-rithms

� Geometrical searching and iteration� Parameter interpolation, e.g. elevation,

thickness interpolation� Curvilinear transformation.

N

ribbon nodes and verticesribbon verticesribbon nodes

a - Road axisc - Road surface

d - Machine path

b- Road edge

t1

t2 tn

diagonals

Figure 6. Sample ribbons in geographic coor-dinates representing: a - road axis, b – roadedge, c – road surface and d - machine path

4.4. XML interfaces

The interfaces between the on-board and theOffice components are based on the XML stan-dard. XML standard is wide spread in Internetapplications and many tools are available. Aconcept central to XML is the separation of theinformation contents and format. The informa-tion contents of the geometry-based OsyrisXML files is based on ribbon concept.

At the beginning of work the on-board mustbe supplied with mission information (worksitegeometry, designed values of the work pa-rameters like speed, fleet configuration). At theend of the work the achieved information has tobe exported. There is also a request-responseschema, allowing the transfer of the currentwork state at any time. The detailed schema hasbeen defined for each exchange file format.

5. DISTRIBUTED OPERATION

5.1. Wireless communication

Wireless communication between machinesis based on a reliable multicast implementedupon Internet datagram (UDP) protocol. Typi-

6

cally WaveLANs are used as physical trans-port. Ribbons with parameters are automati-cally synchronised among the machines. Thisproperty can be used to implement distributedalgorithms (see the following subchapters).

5.2. Distributed pass counting

One of the most valuable information con-cerning the quality of compaction comes fromthe pass counting. Given the past position ofthe compactor, the number of the done passescan be calculated for each point of the surface,resulting e.g. in a compaction coverage map.On the most worksites at least two compactorsare working together. The coverage map is onlythen useful if it contains passes from all themachines, and this is guaranteed by the wirelesscommunication algorithm.

5.3. Cooling model

Another important parameter to take intoaccount during the asphalt laying is the tem-perature of the asphalt layer. Attempts to meas-ure the surface temperature of the asphalt at thecompactor using infrared sensors are unreliabledue to the high influence of the wind speed onthe surface temperature.

Ribbon DB

WirelessTransmission

Compactor

PaverSensors

OPC Server Calculation

CANopen

OPC Sever

Presentation

Ribbon DB

Figure 7. Cooling model as an example of adistributed application in the OSYRIS system

To calculate the evolution of the tempera-ture inside an asphalt layer, a mathematicalmodel has been used. The model parameterslike layer thickness and asphalt temperature at

laying can only be measured at the time ofpaving on the paver, but the results of the coretemperature calculation are most interesting forthe compactor operator, giving him the veryvaluable information about the time left to fin-ish the compaction (Fig. 7.).

6. CONCLUSIONS

The presented on-board structure is univer-sal: all the relevant process parameters are rep-resented in uniform and coherent way and canbe transparently accessed on all the levels ofthe system. Pre-existing standards have beenused as a base for the Osyris interfaces.

The presented solution grants the requiredflexibility and enables advanced, distributedfunctions, for example distributed pass count-ing and real-time simulation of the asphaltcooling (cooling model).

Validation of the proposed framework onthe worksite is planned for Autumn 2002. Thespecifications of the interfaces will be pub-lished at the end of the project.

Acknowledgements

The work described in the paper was carriedout in the framework of the European ProjectOSYRIS: Open System for Road InformationSupport (Growth No. GRD1-1999-10815),2000-2003 [5].

7. REFERENCES

[1] J. Jurasz, Universal digital environmentmodel for computer integrated road con-struction. Proc. 18th ISARC 31-36, Cracow2001

[2] A. Ligier, J. Fliedner, J. Kajanen, F. Peyret,Open System For Road Information Sup-port. Proc. 18th ISARC, Cracow 2001

[3] F. Peyret, J. Jurasz, A. Carrel, E. Zekri, B.Gorham: The Computer Integrated RoadConstruction project, Automation in Con-struction 9 (5-6) (2000) pp. 447-461.

[4] OPC Foundation athttp://www.opcfoundation.org

[5] Osyris Website at http:// www.osyris.org