Guidelines for the design and operation of road management systems Transport Research LaboratoryDepartment for International Development Old Wokingham Road 94 Victoria Street Crowthorne, Berkshire, RG45 6AU London, SW1E 5JL ORN 15 Overseas Road Note 15 First Published 1998 ISSN 0951-8797 Copyright Transport Research Laboratory 1998. Transport Research Foundation Group of Companies Transport Research Foundation (a company limited by guarantee) trading as Transport Research Laboratory. Registered in England, Number 3011746. TRL Limited. Registered in England, Number 3142272. Registered Offices: Old Wokingham Road, Crowthorne, Berkshire, RG45 6AU. This document is an output from a project funded by the UK Department for International Development (DFID) for the benefit of developing countries. The views expressed are not necessarily those of the DFID Subsector : Transport Theme: T2 Project title : Road Network Management Project reference : R6024 TRL is committed to optimising energy efficiency, reducing waste and promoting recycling and re-use. In support of these environmental goals, this report has been printed on recycled paper, comprising 100% post-consumer waste, manufactured using a TCF (totally chlorine free) process. ACKNOWLEDGEMENTS This Overseas Road Note provides detailed guidance on the design and ope ration of computer-based road management systems. It has been issued in parallel with a reference text book published by Macmillan Press Ltd covering the wider area of road maintenance management (Road maintenance management: concepts and systems by Robinson, Danielson and Snaith). Mr C C Parkman (TRL) was project officer and editor. The original draft of the Note was prepared by Dr R Robinson in association with May Associates. Contributions were also made by Dr J Rolt, Mr T Toole, Mr P May and Mr R Abell. Mr H Lewis perfo rmed a final technical edit. The Note draws on material from a number of sources as well as experienc e gained by this team working with many institutions. Chapter 3 has been developed from guidelines produced by May Associates for the European Commission. The recommendations for information quality and data design are developed from work at the World Bank. Much of the document draws on the on-going research carried out by TRL in this subject. The helpful comments of Mr H S Thriscutt and Mr N Ings on earlier versio ns of the draft are gratefully acknowledged. OVERSEAS ROAD NOTES Overseas Road Notes are prepared principally for road and transport auth orities in countries receiving technical assistance from the British Government. A limited number of copies is av ailable to other organisations and to individuals with an interest in roads overseas, and may be obtained from : International Development Advisory and Information Unit Transport Research Laboratory Crowthorne, Berkshire, RG45 6AU United Kingdom Limited extracts from the text may be reproduced provided the source is acknowledged. For more extensive reproduction, please write to the address given above. CONTENTS Page 1 Purpose and structure of the note 1 Purpose 1 Structure 1 Part A: Principles 3 2 Road management 5 Categories of work 5 Management functions 5 The management cycle 5 Introducing procedures 7 Computer-based systems 7 3 Approach 11 External factors 11 Institutional factors 12 Stages in the design process 12 Multiple system implementation 12 Use of technical assistance and the private sector 12 Part B: System design 15 4 System requirements 17 Identifying objectives 17 Cost-benefit analysis 17 Priorities for system implementation 19 5 System specification 23 Identifying the system users 23 Confirming system outputs 23 Identifying data and models 24 Information quality levels 24 Types of model 26 Criteria for model selection 27 Model calibration 27 6 Specification of network information systems 29 7 Specification of planning systems 33 iii iv Page 8 Specification of programming systems 39 9 Specification of preparation systems 43 10 Specification of operations systems 49 11 Computer requirements 53 Sources of procurement 53 Customisation 53 Modular approach to software 53 Programs and databases 53 Hardware 54 Part C: System operation 55 12 Training 57 Training needs analysis 57 Training levels 57 Training topics 57 Monitoring training 60 13 Systems management 61 Defining responsibilities 61 Control of systems and data 61 User access 61 Data updating 61 Data control 62 Monitoring and feed-back 62 Institutional issues 62 Technical issues 62 14 References 65 Appendix A: Glossary of terms 67 Appendix B: Institutional appraisal check list 73 Appendix C: Example applications of the information quality level concept 78 1 1 Purpose and structure of the note Purpose 1 . 1 This Note is intended for engineers and managers in road administrations who are responsible for the specification, procurement, implementation and operation of computer-based road management systems. It offers guidance to help them reach informed decisions about the type of road management system which will best match the needs of their administration and the most effective methods to be used for operating the system. 1 . 2 As well as explaining the benefits which computers can bring to the task of data management, the Note points to the problems that can occur if computer-based systems are designed inappropriately or operated without a full awareness of their strengths and limitations. The aim is to alert managers to these risks so that, in planning and implementing their systems, they can take steps to prevent problems from developing. Engineers and managers do not need to be computer specialists to gain advantage from the Note; but they should be familiar with computer applications such as spread sheets and word processing programs, in addition to having a sound basis of professional experience in road management. 1 . 3 The Note does not discuss management methods which do not rely on computers, though manual processes are likely to be involved to some extent in any system. Manual management methods are described in Overseas Road Note 1 (TRRL Overseas Unit 1987) for road maintenance systems, and Overseas Road Note 7 (TRRL Overseas Unit 1988b) for bridge inspection and data systems. 1 . 4 While the Note is not addressed to organisations engaged in developing or marketing road management systems, or to institutions funding projects for system implementation, they too may find it a useful source of reference. Structure 1 . 5 The Note has three main parts, each focusing on the priorities of a different level of responsibility in the road administration. Part A is meant for senior policy and decision-makers. It outlines the principles of best practice in road management and the role of computer-based systems in supporting management procedures (Chapter 2), and defines the philosophy underlying the Note (Chapter 3) – in particular, the need to ensure, before a computer-based system is introduced, that the road administration has the institutional capability and the commitment to implement it effectively and to sustain its use over the long term. 1.6 Part B is intended for use by professional staff who have the task of recommending the type of system design to be adopted. It addresses the processes involved in system design, starting by identifying the objectives of the system and the components it needs to include (Chapter 4). It then identifies a generic approach to system specification, based on the outputs that might be delivered by the system and the data and computer models required to produce those outputs (Chapter 5). 1 . 7 Chapters 6 to 10 discuss in turn the development of specifications for management systems concerned with road network information, strategic planning, work programming, work preparation and operations, while Chapter 11 reviews the procurement of computer software and hardware. 1 . 8 The operation of road management systems is the subject of Part C, which is intended for staff involved in system implementation. Chapter 12 deals with the training and competence-building activities needed within an administration to ensure the successful introduction of a computer-based system and its continuing operation. Issues related to the day-to-day management of the system are covered in Chapter 13. 1 . 9 The Note concludes with a series of Appendices which provide reference material and background information on specific issues raised in the main body of the text. 2 3 Part A: Principles 4 5 2 Road management 2 . 1 Road management starts from the premise that the road network is an asset which needs to be maintained and improved so as to secure the best performance and value-for-money and the maximum service life. The aims of road management are to enable the network to withstand the damage caused by wear and tear, to prevent sub- standard conditions from developing, and to ensure that traffic can continue to travel, in a manner which is safe, efficient, reliable and which causes the least damage to the environment. These aims are achieved through a series of works and activities which depend for their effective management on the maintenance of up-to-date information about the features and condition of the road network. Categories of work 2 . 2 The works and activities undertaken as part of road management are generally categorised by their frequency and the budget from which they are funded (Table 2.1). The terms used in the table are explained in the glossary which forms Appendix A. Management functions 2 . 3 The management of these works and activities is best viewed in terms of four main functions:
Planning.
Programming.
Preparation.
Operations. 2 . 4 Table 2.2 indicates the application of these management functions within a road administration. The progression from planning through to operations is accompanied by several changes in emphasis:
The focus of attention is transferred from the network as a whole to the specific locations where works are being undertaken.
The time horizon narrows from a span of several years to the individual budget year and then down to the current week or day.
The level of management responsibility decreases.
The information required for each function changes in scope from summary or sampled data about the entire network to detailed and precise data about specific road sections.
Where computer systems are used to support management activities, automated processes which produce standard reports on a pre-defined basis are progressively replaced by processes in which managers work interactively with the computer.
There is a transition from tasks which are conventionally viewed as client function to tasks which are increasingly amenable to being contracted out. The management cycle 2.5 In performing each of the four road management functions set out in Table 2.1, managers need to follow a logical and clearly defined sequence of steps. This approach, termed the ‘management cycle’, is shown diagramatically in Figure 2.1. Each successive step in the cycle requires an accurate and up-to-date supply of information if the correct decisions are to be made. For this reason, the maintenance of a database of management information is at the heart of the cycle. 2 . 6 Road management can be viewed as a process which integrates the cycles of activity involved in each of the management functions of planning, programming, preparation and operations. While these functions have different objectives, they draw on a shared fund of information about the road network: in other words, there needs to be a continuous flow and Table 2.1 Categories and examples of road management works Category Frequency Budget Examples Routine At intervals of less than 12 months Normally recurrent - Cyclic maintenance - Reactive maintenance Periodic At intervals of several years Recurrent or capital - Preventive maintenance - Resurfacing - Overlay - Pavement reconstruction Special Cannot be estimated with certainty Special or contingency, - Emergency works in advance but sometimes recurrent - Winter maintenance Development Planned at discrete points in time Normally capital- Widening - Realignment - New construction 6 Implementactivities Assess needs Determine actions Determine costs and priorities MANAGEMENT INFORMATION (Data) Monitor and audit Define aims Figure 2.1 The management cycle Table 2.2 Road management functions Management Function Typical management aims Network coverage Time horizon staff concerned Planning  Defining road Entire network Long term (strategic) Senior managers and standards which policy-makers minimise cost  Determining the budget required to support defined standards Programming Determining the work Sections likely to Medium term (tactical) Managers and budget programme that can need treatment holders be undertaken within the budgetary period Preparation  Design of works Contract or work Budget year Engineers, technical packages and contracts staff  Preparation and issue of contract or work instruction Operations Undertaking tasks as Sub-sections where works On-going Works supervisors part of works activity are taking place 7 feedback of data both within each management cycle and between successive cycles. Table 2.3, which spans the whole process of road management, shows examples of management cycles and their component tasks. Introducing procedures 2.7 To ensure consistency in its approach to each management function, a road administration should have a clearly defined policy framework. In order to adhere to the standards as set out in this framework, it is important, amongst other things, to introduce and document procedures for each activity in the road management process. A procedure will normally specify:
the purpose and objective of the activity;
the units within the administration to which it applies;
the meanings of any terms requiring definition used in the procedure;
the component tasks of the activity, shown as a logic network, flow chart or work plan;
the responsibilities for fulfilling the procedure which attach to particular posts within the administration, including requirements for liaison and consultation;
any special considerations of health and safety and environmental protection which may apply to the tasks covered by the procedure. 2 . 8 If a procedure is to work successfully, the staff who will be involved in managing and implementing it need to understand what it is intended to achieve, and it has to be accepted as a logical and practical course of action. For this reason, it is important to consult them when the procedure is being drafted and to give them an opportunity of contributing to its detailed formulation. The aim is to arrive at a procedure which staff regard as helping rather than hindering their work, and to which they can feel a sense of professional commitment. The quality of road management practice is largely dependent on the degree to which appropriate and clearly documented procedures are applied within a road administration. So far as developing a computer-based road management system is concerned, it will be difficult to achieve worthwhile results until sound and effective management procedures are in place. Computer-based systems 2 . 9 Once an administration is equipped with these procedures, it makes sense to consider introducing a computer-based system to assist in the process of road management. There is, of course, much that can be achieved in road management through the use of manual techniques: operating check-lists, equipment use and maintenance cards, diagrams and wall charts have a part to play even in the most advanced management system. But effective road management requires continuous access to information about every aspect of the road network and the activities undertaken to keep it in good condition. With their power and relatively low cost, modern computer systems are ideally suited to assist in this task, particularly where large amounts of data have to be managed. Even so, it needs to be remembered that the sole purpose of computer-based systems is to support the human resources engaged in the management process, and not the other way round. 2 . 1 0 Each of the management functions inherent in the care of the road network can benefit from the power of computers, notably through the creation and maintenance of a network-wide database. It is essential to use a computer system as a means of reinforcing the effectiveness of agreed procedures, rather than allowing it to dictate the way road management is to be performed. In the past, computer systems have sometimes been brought into operation without being matched correctly to the priorities and procedures of the administration. As a result, they rapidly lose credibility. The situation becomes even worse when the operational procedures of the road administration are expected to change to reflect the particular requirements of a proprietary computer system. 2 . 1 1 Two types of computer-based systems are used in road management:
network information systems , which correspond to the core of the management cycle (Figure 2.1) and are used to assemble, organise and store data about road network
decision-support systems , which are used in each stage of road management to assist in the tasks that form the perimeter of the management cycle – planning, programming, preparation and operations; they process network data as a basis for decisions about road management activities and almost always require a fully functioning network information system. 2 . 1 2 Terms such as ‘maintenance management system’ and ‘pavement management system’ can easily cause confusion, since systems described as such and produced by different vendors often possess quite different characteristics. Table 2.4 gives examples of the way systems offered in support of road management functions are commonly described. 8 Table 2.3 Examples of management cycles for road management functions Management functions Steps in the Planning Programming Preparation Operations management (Cycle length (Cycle length (Cycle length (Cycle length cycle typically 3-5 years) typically 1 year) typically less than 1 year) typically days or weeks) Define aims a) Determine standards Determine work a) Design of works Undertake works activity that minimise total costs programme that can be carried out b) Issue of contract b) Determine budget with next year’s or work instruction required to support budget given standards Assess needs Assessed using surveys Assessed by comparing a) Assessed by Extent and quantity of of aggregate network condition measurements undertaking detailed work is assessed: condition for periodic with standards for surveys to assess  From detailed inspections and some reactive works, periodic and some condition and for reactive and and using historical data reactive works, and compared with design periodic works for cyclic and special historical data for standards for periodic works cyclic and special works and development works  From the standard (other works notfor cyclic works (will normally designed) depend on the nature of the works for special b) Appropriate form works) of contract or work instruction selected Determine a) Treatments determined Works options that a) Design options Appropriate performance actions by applying a range of are available to restore determinedstandard is selected standards to give budget conditions to for the activity requirements spanning standards are b) Options for the required range determinedspecifications determined b) Treatments determined by applying fixed standards Determine costs a) Application of cost Cost rates are applied a) Cost rates are Apply targets, and labour, and priorities rates to give budget and options prioritised applied and prioritiesequipment and material requirements, with to produce aare possiblyresource requirements treatments prioritised programme withinreconfirmedfrom standard to meet budget the budget constraints b) Bill of quantities prepared b) Application of cost rates to determine budget requirements, with no prioritisation Implement a) Publish standards Submit works a) Undertake design, Undertake and supervise activities programmeproduce drawings, etc work b) Publish forecast budget needs b) Prepare and let contracts or issue work instructions Monitor  Review forecasts prior  Review programme  Review or check design,  Review achievement and audit to start of next planning produced prior to start or contract or work against target cycle of next programming instruction cycle  Review procedures  Review planning  Review designfor managing works procedures  Review programming procedures activities procedures 9 Table 2.4 Examples of different system descriptions Related management function System description Planning Strategic analysis system Network planning system Pavement management system Programming Programme analysis system Pavement management system Budgeting system Preparation Project analysis system Pavement management system Bridge management system Pavement/overlay design system Contract procurement system Operations Project management system Maintenance management system Equipment management system Financial management/accounting system 10 3 Approach 3.1 The guidance set out in this Note reflects a structured approach to the design and operation of computer-based systems. Its key principle is the need to ensure that a road administration has the institutional capability to specify a computer- based system which will match its requirements and priorities correctly, and that it has the competence to use the system efficiently before investing resources in the procurement of hardware and software. In the past, there has been a tendency for road administrations to review the existing range of commercial products and then simply choose the one which appeared to have the most functionality within the available procurement budget. This course of action, which omits a rigorous and comprehensive assessment of a road administration’s abilities and requirements, has usually proved unsuccessful, with the result that resources have been wasted and administrations left with systems which created more problems than they solved. 3 . 2 A computer-based system is a technical response to the challenge of managing and applying road management data. For this response to deliver its expected benefits, two prior conditions have to be fulfilled: first, the social, economic and regulatory context in which the road administration functions – the set of external factors which govern its activities – needs to be conducive to effective performance; and second, the road administration itself has to develop the institutional competence to support the introduction of a computer-based system. The relationship between technical, institutional and external factors is shown in Figure 3.1. Simply implanting a computer system in an organisation that is ill-equipped to use it will be a waste of resources; without the underlying base of institutional capability and external support, the pyramid will collapse. 3 . 3 This principle holds good whether the organisation responsible for managing the road system is in the public or the private sector. Technical factors Institutional factors External factors Figure 3.1 Hierarchy of factors affecting road management (the ‘Brooks pyramid ’) Organisations will have differing strategic objectives – for example, a public sector administration may be concerned to maximise overall social benefits from the road network, whereas for a private toll road operator maximising revenue may be a corporate priority – but in both cases the feasibility of a computer-based system depends on the capability to sustain it. Experience from road administrations in industrialised economies shows that the implementation of a new management system, with all its institutional changes, takes a period of between five and ten years and requires a considerable investment of financial and human resources. The process should not be expected to require less time or investment in developing and emerging economies. 3.4 The external and institutional factors that determine the feasibility of a computer-based system need to be addressed before any start is made on designing the system. External factors 3 . 5 By definition, external circumstances such as the state of the economy, the legal and regulatory framework and, to an extent, the budgetary limits within which the road administration is required to operate are outside its own control; but it is essential for any administration setting out on the path of computerisation to try to secure the most favourable climate for change. Measures which need to be explored include:
obtaining from government a commitment to view road management as an economic priority and to provide the necessary funding to launch management systems successfully and sustain their operation over the long term;
gaining government commitment to the establishment of effective legal, regulatory and administrative mechanisms to reinforce the responsibilities and powers of the road administration; 11
examining the potential for innovative methods of financing and possible partnerships with the private sector, to see whether these may offer a more dependable continuity of funding;
promoting the concept of efficient road management both in government circles and in the wider public forum (for example, by publicising the economic and political consequences of not maintaining the road network to the required standards);
communicating effectively the message that neglected roads mean higher operating costs for all road users. Institutional factors 3 . 6 As a further preliminary step, the road administration needs to undergo an institutional appraisal that will assess its readiness and suitability for the introduction of a computer- based system, identify management characteristics which may constrain the effective implementation of the system, and provide the basis of a programme of action to resolve constraints and improve and strengthen the technical capability of the administration. An example of the factors which have to be examined in this appraisal are listed in Appendix B. 3 . 7 One important point to confirm as part of this appraisal is the degree to which senior management staff of the administration understand the implications of computerisation and share an intention to meet the institutional and technical challenges which it presents. Stages in the design process 3.8 The steps which result from the institutional appraisal may be categorised as the logical and physical stages of the design process. The first step in the logical design phase, that of obtaining commitment to proceed with the development of any system, is of prime importance and its need cannot be overstated. Without a firm commitment from an organisation, both with regard to external factors (3.5) and also institutional factors (3.7), there will be limited potential for a system achieving its objectives. 3.9 The logical design stage starts from a commitment on the part of the administration to introduce the system and make it work. The administration has then to confirm the objectives of the system and decide its requirements in terms of the components to be included. This leads to the preparation of a detailed specification for the system, which identifies users and their required outputs and hence defines the required data and analytical processes. 3.10 The physical design and implementation stage focuses on the technical aspects of the system. It covers the procurement and commissioning of the appropriate hardware and software and the operational, training and management measures that bring the system into implementation. 3.11 Figure 3.2 shows the overall sequence of stages and activities forming this design process. The sequence is fully consistent with the structured approach to systems design applied in the information technology sector. 3.12 The approach may appear unduly complicated for a small system, but its applicability needs to be viewed against the potential costs of implementing and operating the system. These costs are normally dominated by the expense of data collection. In the absence of a rigorous approach to system design, there is a considerable risk that data requirements will be specified inappropriately, with the result that the costs of acquiring and maintaining data far outweigh the practical benefits of the system. Multiple system implementation 3 . 1 3 An institutional appraisal may sometimes indicate a requirement for several different types of computer-based system. In such cases the process of implementation has to be undertaken carefully and needs to be phased in gradually as part of a long-term development plan. The temptation to try to do everything in a single bout of procurement should be avoided; experience suggests that it is much better to move forward step by step. In this way each step is fully assimilated within the administration before moving on to the next. This type of approach should enable the administration’s longer-term objectives to retain flexibility for change and adaptation, while allowing each successive stage of implementation to benefit from the build-up of experience and competence. Use of technical assistance and the private sector 3 . 1 4 Systems do not necessarily need to be developed in-house by the road administration. Box 3.1 indicates parts of the process where the use of consultants and other sources of technical assistance from the private sector may offer advantages. 12 COMMITMENT REQUIREMENTS Systems requirements Chapter 3Chapter 4 Chapter 5 Examples included in Chapters 6 - 10 Chapter 11 Chapters 12 and 13 SPECIFICATION Users and outputs Data Models PROCUREMENT Computer requirements OPERATIONS Systems management Training Figure 3.2 Overall approach to the design and operation of systems 13 Box 3.1 Use of technical assistance from the private sector Requirements During the requirement phase, some knowledge of the market may be helpfu l to confirm what is technically feasible. It can be useful to seek an objective outside asse ssment. Those involved within the roads administration may lack up-to-date knowledge of the capabiliti es of modern systems, or may find it difficult to identify the real business benefits of systems being considered. Similarly, few consultants have in-depth knowledge of developing and implementing a wide range of systems. Those that are experienced often have proprietary systems of th eir own. Such systems may be very competent and robust, but may not meet all of the requiremen ts of the road administration. Clearly, the choice of objective outside assistance, and the terms of reference for its employment, are important. Specification During the specification phase, the investment should be justified in te rms of costs and benefits. A specification can then be written that focuses on the minimum facilities that are needed to deliver those benefits. At this stage, it is vital to avoid expansion of the sco pe of the system (as this can affect the cost significantly) without being sure that the incremental benefits outweigh the additional costs. There have been many examples where the perception of the success, or otherwise, of a new system has been affected because of unrealistically high initial expectations. When drafting specifications, it is important that engineering requireme nts are translated into a suitable logical design that can be understood by information technology (IT) specialists. Procurement Available products should be reviewed, either as off-the-shelf solutions , or as a basis for local customisation. The cost of this approach can then be compared with the c ost of bespoke development. The sustainability of any off-the-shelf systems should alwa ys be reviewed in terms of the required on-going support that might be necessary after initial impl ementation. Each case will be slightly different, but it should be noted that purpose-written syste ms are normally considerably more expensive than customised products, irrespective of whether the wor k is done in-house or by outside firms. Engineers are advised to seek the advice of IT experts to write operational requirements (i.e., the functional user requirement of the system), de tailed specification and contract documents, as appropriate. The procurement should be handled by someone who is familiar with computer system projects, but always with reference back t o the road administration in the event of technical queries. Operation The greatest disappointments often occur during system implementation. T he setting of unrealistic delivery schedules and underestimation by the road administration of the time required to collect, load and validate data, can all contribute to delays. Firm project manag ement is required and outside assistance may be appropriate. The private sector can also be us ed to assist with on-going operation of the system. Tasks such as network referencing, inventory co llection, traffic counts, axle load surveys, and condition surveys (carried out by manual methods and by machine) can all be undertaken in this way, often more cost-effectively than by the road administration using its own resources. These works are relatively easy to define and, in several cou ntries, specialist contractors have evolved for these activities. Similarly, for bridge management, con sultants and contractors can often bring specialist skills and equipment to the tasks of bridge inspe ction and assessment. More radically, consultants can be used for all aspects of system operation, including the provision and operation of all hardware and software. Use of the private sector also g ives access to state-of-the-art technology without the need for investing directly in development costs. Such an approach reduces the need for institutional development within the public sector. Source: Britton, C, 1994. Computerised road management: the appliance of computer science. Highways, 62 (No 4). London: Thomas Telford, pp. 12-13. 14 15 Part B: System design 16 17 Box 4.1 Use of a policy framework approach in deciding system objectives System objectives can be defined by reference to the objectives of the r oad administration. A typical objective in the area of road user costs might be:Arterial roads will be maintained, so far as budgets will allow, to mini mise the sum of road user and road maintenance costs in the longer term. This objective would need to be met by a system designed to minimise the longer-term road user and road maintenance costs in a constrained budget situation. An appropriate plan ning system would be required to help achieve this objective. Decisions would be needed about which road user costs (vehicle operation, travel time, accidents, and so forth) should be included, since the phr asing of the objective does not specify this point. In addition, turning longer-term plans into actual programme s of work, with agreed budgets, and arranging for the budgeted work to be performed would require the implem entation of programming and preparation systems. Similarly, a typical road administration cost objec tive might be: The road administration will endeavour to provide value-for-money by mee ting the above objectives at minimum cost, subject to the available budget. An operations system would be needed to support this objective. The scop e of the system could include the facility to develop effective costing procedures for works, and the generation of work records that could be used to monitor and audit performance against targets. 4 System requirements 4.1 Defining the requirements of the systems needed within the administration is a matter of identifying the objectives which each system is intended to fulfil, and determining the components needed to meet these objectives. Identifying objectives 4 . 2 Two approaches can be used to help identify system objectives. The first is related to the framework of strategic policies adopted by the road administration; the second uses a method known as ‘problem tree analysis’. 4.3 The policy framework approach derives its logic from the principle that the introduction of new technology should assist the administration in achieving its strategic objectives. It therefore makes sense for the objectives of the computer- based system to reflect the broader policy framework adopted by the administration, in terms of its overall aims and the means by which achievement of these aims is measured. Box 4.1 offers examples of the use of this approach. 4 . 4 The method termed ‘problem tree analysis’ examines the effects of problems identified within an organisation to determine their basic causes. The results of this analysis are then used to identify the means of achieving the desired solution or objective. The method is described in more detail in a document on project cycle management produced by the Commission of the European Communities (1993). 4 . 5 Problem tree analysis establishes cause and effect relationships between the negative aspects of the existing situation, and identifies ‘bottle- necks’ that should be treated as matters of priority. The results of the analysis can be recorded in a tree diagram showing the effects of a problem and its causes. The ‘negative situations’ of the problem tree diagram are then converted into ‘positive achievements’ in the diagram by replacing the causes of the problem with the means of achieving the required end. The effect of the problem will generally have several impacts and causes, and several means and results will be needed to achieve the objectives by addressing all aspects of the problem. 4 . 6 Box 4.2 sets out an example of problem tree analysis in the field of road management. This demonstrates the conclusion that the implementation of a road management system is likely to be only one component of an overall solution. A range of measures will normally be required to help improve road management capabilities within an administration. Cost-benefit analysis 4 . 7 The decision to introduce a computer-based road management system has to be seen as a business decision, not as simply a technical option. This decision needs to be reached on the basis of a 18 Box 4.2 Use of problem tree analysis A road administration may be concerned that its road maintenance activit ies are incurring costs which perhaps seem high by international standards, or when its overall costs per km are compared with those of neighbouring administrations. Analysis of this problem might identify several possible causes of high cost levels. These could be shown in the form of a problem tree, such as that below, which only isolates one of a number of possible causes. The tree diagram can help identify possible solutions to the problem. Th e effect of the problem ‘high road maintenance costs’ can be converted into the objective of achieving ‘ lower road maintenance costs’. The impact of ‘inefficient use of resources’ can be converted into the desired result of ‘effective use of resources’, and the cause of ‘lack of resource management’ can be converted into the means of ‘implementing an operations management system’, as illustrated bel ow. Cause 1 Other causes Lack of effective resource management Impact 1 Inefficient use of resources Other impacts Effect High road maintenance costs Cause 1 Other means Implement operations system management Impact 1 More efficient use of resources Other results Objective Lower road maintenance costs Result Means 19 comparative assessment of costs and benefits. Though it is not always easy to quantify the potential benefits of the system, experience suggests there is a real risk of costs escalating out of control unless they are analysed carefully in advance. 4.8 The costs of a computer-based system will typically be incurred by:
data collection and updating – the principal cost item;
hardware and software;
staff training and retraining. 4 . 9 The benefits of the system are likely to result from:
improved asset management;
improved control of contracts and costs;
better management information. 4 . 1 0 Cost-benefit analysis should follow normal procedures for an economic appraisal in the road sub-sector, as set out in Overseas Road Note 5 (TRRL Overseas Unit 1988a). 4.11 Boxes 4.3 and 4.4 offer examples respectively of costs and benefits typically associated with the introduction of a computer- based road management system. Priorities for system implementation 4.12 The order of priority for implementing systems of different types will be determined from the assessment of requirements, supported by the results of the cost-benefit analysis. Each road administration will have specific needs, but in most instances the first priority will be to introduce a network information system, if one is not already in place. The reason is that a more comprehensive and reliable base of information about the road network can in itself yield significant benefits to the administration. In any event, all other types of system require a network information system as a database on which they can operate. 4.13 Issues determining priorities for implementation include the following:
the level of institutional development within the road administration;
the nature of the administration’s existing procedures;
the form of work procurement - i.e. in-house or contracted out;
the competencies of staff at various levels in the organisation. 4 . 1 4 There are also other factors to be considered. Operations systems may hold out the possibility of greater benefits to the road administration, but planning systems are likely to be easier to implement, even though the immediate benefits may be less. This is because planning systems may require fewer data to be collected on a relatively infrequent basis, and will be operated by staff in the organisation who are more likely to have computer skills. Box 4.5 provides additional examples of system implementation priorities. 4.15 Funding agencies such as the World Bank, EBRD or the European Community may well attach the highest degree of priority to a planning system, since this will provide the macro-level data which funding agencies find useful when developing the sector policy for a country. 20 Box 4.3 Typical costs of implementing a road management (planning and progr amming) system Implementation costs Computer hardware Cost of new hardware or the upgrading of existing facilities to the standard of the new system, including computers, printers, storage devices, cabling, and so forth System System licence cost Other software licences Cost of licences for software purchased for, or for use with the system, including database management system, system interfaces, and so forth Data collection equipment Cost of equipment purchased for use with the system, including data capture devices (data loggers), rut depth measuring devices, distance measuring devices and safety equipment for condition surveys; this would include the cost of vehicles if purchased solely for use with the system Establishment of network All costs of setting up or integrating an existing referenced network for the system Entry of network to database Personnel and other costs of entering the network into the system database Collection of inventory Cost of item inventory collection or the upgrading of existing inventory Entry of inventory to database Personnel and other costs of entering inventory to the system database Initial staff training Cost of training staff to facilitate the introduction of the system, including training of inspectors, computing staff, engineering staff, and so forth Source: UKPMS Annual running costs Computer support staff Cost of all staff involved in providing support to computing operations Engineering staff Cost of all engineering staff including inspectors, surveyors, engineers, etc. Maintenance of hardware Cost of maintaining computers and ancillary equipment, including all necessary computer consumables Maintenance of software Cost of in-house maintenance of the system database system as well as any third party software maintenance and upgrade costs Maintenance of network Cost of keeping the network referencing information up to date, including any surveying and data entry Maintenance of inventory Cost of keeping inventory data up to date, including inventory surveys and data entry Maintenance of equipment Cost of maintaining data collection equipment, including vehicles Record keeping and presentation Cost of collecting and presenting records Preparation of annual maintenance programme Personnel costs Production of scheme plans Personnel costs Note: In some cases, these costs will need to reflect the annualised cost of items not expended in every year 21 Box 4.4 Typical benefits of implementing a road management (planning and pr ogramming) system Better economic management:
Priorities based on economic return; treatments selected on the basis of highest return on investment in different maintenance options within a constrained budget.
Priorities based on projection of pavement condition; treatments selecte d for the time that they are applied, based on projection of pavement condition rather than existing condition. Improved advice:
Availability of information on historic and future trends to assist in e stablishing budget requirements and formulation of investment policies.
Possibility of authority-wide assessment and management for different pa vement types, footways, cycle tracks, and so forth. Better design:
Selection of treatment being based on the separation of defects into tho se relating surface, structure and edge (on asphalt pavements) or joints (on concrete pavements).
Incorporation of historical data into the design process.
Ability to consider combinations of machine-derived and visual condition data.
Interfaces with other highway management systems in use. Improved monitoring:
Automatic recording of original defects, design decisions and informatio n, and works records Improved general management:
A more comprehensive and complete system than those commonly in use, app licable through all stages of the pavement management process from defect identification to the implementation of works, and suitable for use by all the different types of highway author ity.
Ability to define different inspection cycles to meet needs of different authorities; encouragement for the use of network and project level surveys which make better use o f engineering resources.
An assessment system which can operate at appropriate but different leve ls of detail on major and minor roads.
Ability to collect data at different levels of detail depending on the i mportance of the highway feature being assessed.
Output provided in a more readily understandable form, using text and gr aphics in conjunction with a flexible enquiry system. Source: UKPMS 22 Box 4.5 Examples of system implementation priorities in different situat ions Well-established road administration An administration that is experienced and efficient may have operations and preparation systems already in place. In that event, the prime objective may be to improve the way b udget needs are determined and to develop a strategic planning capability. The priorities would then be as follows:1 Development of a programming system to improve the needs-based determination of budgets 2 Implementation of a planning system to enable scenario analysis of strategic planning options New or relatively inexperienced road administration In an administration where road management practice is not well advanced , and where the control of activities is relatively weak, the most important need may be to ensure that costs and work practices are managed more efficiently. In this situation the following order of syste m implementation may be more appropriate: 1 Ensuring adequate identification and control of costs through the use of an operations system 2 Budgeting and setting priorities under budget constraint by the use of a programming system 3 Introduction of a planning system to provide forecasting tools for assisting with policy formulation and identifying longer-term budget needs 4 Implementation of a preparation system, which would receive the lowest priority since most administrations already deploy reasonably effective manual systems for w orks preparation. Note that operations systems are appropriate mainly in administrations w hich undertake works in-house, though they can be used to assist with the letting and management of con tracts. 23 5 System specification 5.1 After deciding the types of system that the road administration will need, and defining their requirements in terms of objectives and priorities, the next stage in the design process involves the specification of systems – in other words, determining the outputs which each system will need to deliver and the categories of data and models that it will use to produce the intended outputs. 5 . 2 The recommended procedure for system specification is as follows: 1 Identify the prospective users of the system. 2 Confirm the outputs that its users will require. 3 Identify the categories of data and models needed to produce these outputs: this step will entail a process of continual iteration because data and model requirements are interdependent. 5 . 3 This chapter sets out practical guidance on each of these steps as they apply to computer-based road management systems in general. Detailed points of advice on the specification of systems for network information, planning, programming, preparation and operations respectively are offered in the five chapters that follow (Chapters 6-10). 5 . 4 The form of approach recommended here, in which outputs are defined before data and models, is the logical procedure for system specification. It is fundamentally at variance with the way in which many road management systems have been specified in the past, where the emphasis has been on defining models and data requirements at the start. Identifying the system users 5 . 5 This initial step draws on the findings of the institutional appraisal (3.6) to identify which staff in the administration will wish or need to use a computer-based system. Talking to staff, both in workgroups and individually, to determine their attitudes to computerisation and their degree of familiarity with computer processes, is an essential part of this task. External assistance – for example, from IT specialists – also may be useful. Box 5.1 indicates typical categories of user for different road management systems. 5.6 Many users will regard the system as a collection of ‘black boxes’, and they will have no wish to understand its detailed structure or contents, nor should they be required to do so. Their main concern will be to have available a system which produces results that are believable and in keeping with their engineering judgement. The design of the system needs to reflect this priority. Confirming system outputs 5.7 Once the users of the system have been identified, they need to be consulted about the specification of its proposed scope and outputs. While consultation with users is the key to this task, it is important to maintain a practical and realistic view of the results that the system can be expected to achieve and to resist over-ambitious demands. Wherever possible, cost-benefit analysis should be used to assess the likely value of the proposed outputs (4.7-4.11). 5.8 The types of output required will depend on the policy of each administration, on its institutional arrangements, and on the detailed objectives of the proposed system. For this reason, it would be unrealistic to be prescriptive on this point. Chapters 6-10, which deal with the specification of particular categories of system, offer guidance on typical forms of output; but these are put forward only as examples which serve the purpose of demonstrating the types of issues that arise in designing outputs to meet user needs. The actual outputs obtained from particular systems will be determined by the objectives of the system and the specific requirements of its users, and may differ widely from those shown in the examples. Box 5.1 Typical users of road management systems Network information system
All staff in the road administration Planning system
Top management of the road administration
Planning or economics unit within the administration
Funding agencies Programming system
Professional staff in the road management/maintenance department
Budget holders Preparation system
Road management/maintenance department
Design department
Contracts/procurement department Operations system
Works supervisors 24 5 . 9 Outputs will often need to be provided at more than one level of detail: some managers will require only summary information, while others will also want to receive supporting data. Additional outputs should be available to show data inputs, often in the form of data sets with dates and times of processing. All outputs should be clearly and precisely referenced to avoid confusion. 5.10 Most outputs will be produced in a tabular format: all outputs should be available in this format, though some will also be amenable to graphic presentation. For example, the outputs from planning systems, which are intended for use by senior management, can often be communicated more effectively in the form of line graphs, histograms and pie charts. Similarly, many of the outputs from programming systems lend themselves to reproduction as strip diagrams, which provide schematic representations of a length of road. 5 . 1 1 Some systems produce outputs using map- based graphics depicting the whole or part of a network, accurate to scale in two dimensions. While these outputs may be visually attractive, the costs of collecting, maintaining and updating the spatial data needed to support them can be substantial. Before a system with this facility is procured, the additional benefits that are expected to be obtained from map-based graphical presentation need to be reviewed to make sure they will outweigh the recurring data costs. Identifying data and models 5 . 1 2 The outputs of a system are produced from a combination of data and models. Specifying these outputs will determine the data items to be collected and stored within the system and the types of model, in the form of algorithms and relationships, needed to process these data. Since the annual costs of data collection are typically five to ten times as high as the costs of purchasing the computer hardware for a system, accurate data design is essential if the system is to be cost-effective. 5 . 1 3 Table 5.1 identifies information groups which might be used as a basis for classifying data items relevant to road management activities. 5 . 1 4 Box 5.2 comments on the key criteria to be used in selecting data items, which are:
Relevance
Appropriateness
Reliability
Affordability 5.15 As road administrations develop and extend their resources, they will be in a position to adopt improved methods of data collection. Suitable links need to be provided between old and new forms of data to preserve the value of historic information and allow it to be used in trend projection. 5.16 Systems have often fallen into disuse because of their onerous requirements for data collection and processing. Staff may collect huge quantities of data simply because the system has a vast potential for storage. The urge to store every piece of data must be balanced pragmatically against the costs involved in the process, the demands placed on the time of relevant staff, and the practicality of actually making use of the outputs generated from the data. Information quality levels 5.17 In 2.4 it was observed that as the road management process moves from planning, through programming and preparation to operations, the level of detail required in the system data increases (though the extent of the network to which the data refers decreases). Determining the appropriate level of detail therefore depends on the road management function for which the data will be used. 5 . 1 8 An example of the change in data requirements is that of cost estimation, which is a key task in each management cycle. Both the accuracy of cost information and the level of detail will need to become sharper as the process of road management moves through its successive stages. Overseas Road Note 5 (TRRL Overseas Unit 1988a) reviews different methods of cost estimation. Table 5.1 Information groups Element Aspects Road inventory Network/location Geometry Furniture/appurtenances Environs Pavement Pavement structure Pavement condition Structures Structures inventory Structure condition Traffic Volume Loadings Accidents Finance Costs Budget Revenue Activity Projects Interventions Commitments Resources Personnel Materials Equipment Source: Paterson and Scullion 1990 25 Box 5.2 Criteria for selecting data Relevance Every data item collected and stored must have a direct influence on the output that is required from the system. Other data items which may be considered as desirable, interesti ng or possibly useful in the future, should be omitted in favour of those that are essential, relevan t and of immediate use unless a very good cost-benefit case can be made for their collection. Appropriateness The volume of data and the frequency of updating them are major determin ants of the cost of operating the management system. Some types of data are collected at different tim es in a staged process, and the intensity and detail of measurement may differ between these stages, usu ally adding progressively more detail to the basic information acquired originally. For example: for pa vement structural assessment as part of a strategic planning process, data on road condition would need broad coverage across the network, but would have a low sampling rate; however, for engineering de sign of a project at the later preparation stage, intensive sampling over the limited extent of the project would b e necessary to refine the design and contract quantities. The technology and resources involved in acquiring, processing and manag ing the data should be appropriate to the administration’s capacity for maintaining the equi pment, conducting the surveys, and sustaining the data processing. Reliability Data reliability is determined from the following:
The accuracy of the data, defined by a combination of precision (the er ror associated with repeated measurements made at separate times or places, or by separate operators and/or instruments) and bias (the degree to which the mean measurement reflects the range and variab ility of all data points).
Their spatial coverage; for network-level planning, low intensity sampli ng is adequate whereas, for engineering design of projects at the preparation stage, intensive sampl ing is needed with full coverage of the project area.
Completeness of data is important because missing items degrade the reli ability of the outcome.
Currentness ensures that data which change rapidly from year-to-year, or which have a large impact on the ultimate decision, are kept up-to-date more than data whic h do not change so rapidly or are less sensitive. A balance between the reliability of data and certainty of outcome shoul d be sought. For example: high precision, intensive sampling of entire networks, such as can be ob tained using mechanised methods, may represent over-investment if the results are only to be use d for broad planning. Affordability The volume and quality of the data items, and the associated data acquis ition, must be affordable in terms of the financial and staff resources available to collect data and keep them current. The scope and quality of data are choices that must be weighed against the resourc es required to sustain them in the long-term, and against the value of the management decisions that rely upon them. Available resources and skills vary between road administrations, and ma y change over time. For small organisations, or where skills and resources are scarce in a large r organisation, simple and basic types of data, quality and collection methods must suffice. Where skills and resources are more abundant, a wider range of data, including the use of automatic col lection methods, may be appropriate. Problems arise when administrations with very limited resou rces are responsible for managing large road networks. Source: Paterson and Scullion 1990 26 Table 5.2 relates the use of these methods to the component functions of road management. 5.19 The management function that the particular system is intended to support can be related to all the information groups shown in Table 5.1 to provide a rigorous basis for classifying data needs. This is achieved using the concept of information quality levels (IQLs), as shown in Table 5.3. Expressed in simple terms, the relationship between appropriate information quality levels and system types is shown in Table 5.4. Reference should be made to the World Bank document Draft guidelines on system design and data issues (Paterson and Scullion 1990) for detailed recommendations on the appropriate level of data detail to be used for each IQL for many of the information groups shown in Table 5.1. Appendix C provides summaries of data requirements at different IQLs for some information groups based on the Draft guidelines. 5.20 M ost road administrations collect and store network inventory, traffic and finance data at one level only. The data may then be summarised for use in the different applications that compose the system, or selected values only may be used. The exact level of detail of the data collected for road inventory and traffic will be governed by the nature of the road hierarchy. It makes sense for data values to be recorded in only one place in the system since this will help maintain data integrity when values are updated. The network information system should have the ability to reflect these strategies, and to store and report on data at different levels of detail. Box 5.3 outlines typical strategies for data collection. Types of model 5 . 2 1 Models, which contain relationships and algorithms, are often embedded in the design of the system. In road management systems, models are typically used for the following purposes:
representing physical sections of road;
summarising pavement condition as an index based on measured defects;
projecting road conditions over time;
selecting appropriate maintenance treatments based on condition;
estimating and assigning costs to activities;
predicting traffic, in terms of both flows and damaging effects;
congestion analysis;
analysing road user costs;
deriving works priorities under budget constraints;
allocating funding to geographic areas, budget heads, projects, and so forth. Table 5.3 Information quality levels Information quality level Short description Data collection IQL-I Most detailed andShort to limited lengths or isolated samples using specialised comprehensive equipment; slow except for advanced automation IQL-II Detailed Limited lengths using semi-automated methods; or full coverage using advanced automation at high speed IQL-III Summary details withFull sample using high-speed, low accuracy semi-automated categorisation of values methods; or sample at slow speed; or processed from other data IQL-IV Most summaryManual or semi-automated methods, processed or estimated Source: Paterson and Scullion 1990 Table 5.2 Cost estimation methods Detail and Cost of dataRelevant Method Description accuracy of datapreparation management function Global costs ‘Broad brush’ costs related to theCoarse/summary: relatively Relatively low Planning overall size of the works or activity; large tolerances cost per km of road Programming Unit rates Bill of quantities approach; e.g., cost per m 3 of materials Operational costs Costs built up from fundamental Preparation units of equipment, labour and materials needed to complete work Fine/detailed: relatively as defined in a method statement tight tolerances Relatively high Operations 27 Table 5.4 Application of information quality levels System typeInformation quality level Planning IQL-IV Programming IQL-III/IV Preparation IQL-II/III Operations IQL-I/II Criteria for model selection 5 . 2 2 Since each model has its own data requirements, models should be selected on the basis of the same criteria used to select data – namely, relevance, appropriateness, reliability and affordability (Box 5.2). An extensive range of models is available, which it would not be practical to attempt to review in this Note: where an administration does not possess in-house the expertise to evaluate different models, external consultancy assistance may be helpful. 5.23 M odels from the World Bank’s HDM system form part of several road management systems for planning and programming. These models are comprehensive and many of them represent the current state of knowledge in their specific areas. But they are not universally applicable, and care should be taken to ensure that they are used only in appropriate situations, and with local calibration, which can be time-consuming. One disadvantage of these models is that they impose substantial data requirements, typically at IQL-I and IQL-II levels. Before incorporating these models in a system specification, road administrations need to give careful thought to their ability to meet the data requirements on a continuing basis. Model calibration 5 . 2 4 Many models contain calibration factors which allow them to be adjusted to suit local conditions. If these calibration factors are not determined properly, the outputs from the model are likely to be inaccurate and inappropriate. For this reason the calibration of relationships within the model is an important step in the system design process. Box 5.4 outlines a recommended approach to calibration. Box 5.3 Typical strategies for data collection Strategy A High level condition data (typically IQL-IV) are collected across the whole network each year. The data are used for planning and programming purposes. The programming exercise then collects more detailed data (typically IQL-III) on those sections where works are likely to b e undertaken. Further detailed data (typically IQL-II) are then collected on some of the sections for whic h designs are produced, or for which works are undertaken. As more detailed data are collected on any section , they replace the data collected in the earlier phase, with the result that different sections in the dat abase store data at different levels of detail. Strategy B Relatively detailed data (typically IQL-II/III) are collected across p arts of the network on a rolling programme, perhaps with a cycle of three to five years. Each year, progr amming decisions are taken either by using current data for individual sections, if available , or by projecting condition data from previous years. All condition data tend to be stored at the sa me level of detail, though data collected as part of the works design or execution processes may al so be stored. Other strategies Combinations of these strategies are also used, including the following examples:
Annual data can be collected on the primary road network, whereas a cycl e of data collection may be used on roads lower in the hierarchy.
The cyclic approach can be used for the whole network, collecting data a t low levels of detail (IQL-III/IV). Cyclic collection methods can be used without projection of condition.
Detailed data can be collected annually across the whole network, though this approach is probably not cost-effective and is not recommended. All these strategies have different implications for the detail of data stored in the system database. 28 Box 5.4 Understanding network behaviour Many models have been created to suit the conditions of a specific envir onment. Others have been developed and extended to cover a range of different environments and th is is often achieved by including within the models calibration factors which permit their local adaptation. The important point is that the use of any model requires a correct understanding of t he behaviour of the road network. This will ensure that money is not wasted on inappropriate main tenance and rehabilitation measures. To achieve a sound knowledge and understanding of network performance, a n administration should consider monitoring a representative sample of the network on a l ong-term basis. The monitoring will probably be carried out at the IQL-I level of detail. A representative sample should be selected to span the full range of traffic, materials, environments a nd construction methods as appropriate. This activity is often performed by a local research instit ution or similar organisation. 29 6 Specification of network information systems 6.4 Boxes 6.1-6.3 illustrate three examples of outputs from network information systems. Box 6.1 shows a typical roads gazetteer for a district. This is a simple list of all sections in the district road network. Users should be able to select which types of sections in the network to include in the output, and to specify the details that are to be shown for each section. In this particular example the gazetteer includes the section label, section length, start and end node references, and a description of the section. The node references, given as six figure grid co- ordinates, enable the sections to be located spatially. 6 . 5 The information in the gazetteer is shown plotted to scale in Box 6.2. This graphical output indicates each road section with its label, the direction in which data are to be collected on the section, and the labelled nodes. For a plot like this to be produced, strings of grid co-ordinates need to be stored at regular intervals along each section. These are normally obtained by digitising data from maps. Data recording quality needs to be high if this type of graphical presentation is to be meaningful, since errors in the location of sections are obvious when plotted spatially. There are particular problems involved in digitising data from maps where sections extend over the edges of adjoining maps, since the mapping process may cause discontinuities in co- ordinates. Edge-matching is a necessary but tedious process. The plot also shows the position of certain footpaths. If road administrations are responsible for the maintenance of footways and footpaths, sections for these should be created in the same way as for carriageways. 6.1 A network information system forms a central and integral part of the decision-support systems used in road management, as shown in Figure 6.1, and can also be used as a system in its own right. Its purpose is to provide a single point of storage for data on every characteristic of the road network. By definition it is a database which can be interrogated to produce reports. The likely users of network information systems are noted in Box 5.1. 6 . 2 The standard outputs available from a network information system are likely to include:
Gazetteer of road sections, in user-defined order, giving attributes of sections (such as label, description, and other data)
Lists of sections based on user-defined selections of section attributes (for example, all sections in one geographic district, all gravel roads and their total length, all paved roads in a particular district carrying more than 1000 vehicles per day). 6 . 3 It should be possible to report on most of the information stored in a database. User-friendly systems employ customised query languages which give users ready access to reports (sometimes known as ad hoc reports) on relevant data items. In other systems it will be necessary to use the query language of the database software itself. This latter approach may permit a large measure of flexibility in report production, but it is likely to be more difficult to apply than a system- specific report generator. Network information Figure 6.1 The function of a network information system 30 6 . 6 Box 6.3 shows details of a user-selected list of sections in the district. In this example, all details of all unclassified roads have been requested. Details of carriageway length and width, surface, road base and sub-base materials are shown, as are shoulder width and construction type. Certain sections do not have shoulders or, if they do, the relevant information has not been recorded. Traffic has been grouped by ranges (hierarchy or class), indicated for each section on the output. The information system may also store data on other attributes of the section, for which reports would be available in other forms of output.6 . 7 The categories of data stored in a network information system will be determined by the particular management strategy for data collection used by the road administration (5.12-5.19). The key data will belong to the inventory data group shown in Table 5.1. They will need to be stored at the most detailed IQL value required to support the applications included in the system. 6.8 For decision-support systems, all the data required by the system models can be stored with the inventory data. It should be possible to produce output reports on these together with the inventory data. Box 6.1 Example of output of roads gazetteer NETWORK INFORMATION SYSTEM ROADS GAZETTEER PAGE 1 LEAGRAVE DISTRICT DATE: 01-APR-97 SECTION LENGTH NODE LABEL (m) START END DESCRIPTION B486/20 603 563424 572392 Bramingham Road from Derby Rd to Weltmore Rd B486/30 1,750 572392 572341 Bramingham Road from Weltmore Rd to Park Rd B488/10 1,023 514381 539409 Leagrave Road from 50km/h limit to Weltmore Rd B488/20 491 539409 546424 Leagrave Road from Weltmore Rd to district boundary 2U164/10 960 525394 535406 Parkman Crescent from liquor store to bakers 2U210/10 823 534353 522369 May Avenue from Merryn Road to West St 2U245/10 1,166 539409 572392 Weltmore Road from Leagrave Rd to Bramingham Rd 2U257/10 437 564420 569409 Matthews Road from Bramingham Rd 2U258/10 197 573404 566402 Hannah Road from Bramingham Rd 2U259/10 2,264 571362 532340 Merryn Road from Bramingham Rd 2U355/10 703 539360 554340 Margaret Road from Merryn Rd to Telford Rd 2U1401/10 415 553399 546387 Bosmore Road from Weltmore Rd to Carisbrooke Rd 2U1401/20 813 548384 527376 Carisbrooke Road from school to Limbury Path 2U1401/30 419 545389 536375 Icknield Road from Carisbrooke Rd 2U1503/10 339 563365 551361 Larkhall Road from Merryn Rd 2U1504/10 335 551348 562353 Kenilworth Road from Margaret Rd 2U2101/10 266 527354 532363 Ludlow Road from May Ave 2U2102/10 234 522357 515350 Balcombe Road from May Ave 2U2103/10 246 518372 525366 West Street from health clinic to Limbury Path 31 Box 6.2 Example of graphical output of roads gazetteer B488/10 B488/20 B486/20 B486/30 2U257/10 2U245/10 2U1401/10 2U1401/20 2U1401/30 2U258/10 2U259/10 2U1503/10 2U1504/10 2U355/10 2U210/10 2U2101/10 2U2102/10 2U2103/10 2U164/10 539409 535406 525394 564420 569409 573404 566402 553399 548384 546387 545389 527376 536375 571362 563365 551361 539360 551348 562353 534353 532340 527354 532363 525366 518372 522369 522357 515350 Footpaths KEY 2U123/10 545389 Section label Node label Direction ofsection Node Road/section Footpath 572392 32 6 . 9 Network information systems do not use models, although advanced systems may perform arithmetic calculations and store and apply this information to assist in decision making. For example, some systems can estimate cyclic maintenance requirements. These systems can accumulate the total quantities of certain entities or their attributes from the inventory data, and combine these with stored information about standards or intervention levels to determine maintenance quantities. This can be taken further by applying unit costs to the quantities to build up maintenance budgets. In this situation, the network information system is being used as a programming system. Box 6.3 Example of output showing section pavement and traffic details NETWORK INFORMATION SYSTEM SECTION PAVEMENT AND TRAFFIC DETAILS PAGE 1 LEAGRAVE DISTRICT: UNCLASSIFIED ROADS DATE: 01-APR-97C/WAY SHOULD SECTION LENGTH WIDTH WIDTH C/WAY C/WAY C/WAY SHOULD TRAFFIC LABEL (m) (m) (m) SURF BASE SUB-BASE CONSTRN CLASS 2U164/10 960 6.5 0.7 S/D Crsh stn Gravel S/D 4 2U210/10 823 6.3 0.5 S/D Gravel - Grass 6 2U245/10 1,166 6.0 1.0 S/D Stabl Gravel Grass 4 2U257/10 437 6.7 - S/D Gravel - - 4 2U258/10 197 6.3 - S/D Gravel - - 6 2U259/10 2,264 7.0 1.5 S/D Stabl Gravel S/D 4 2U355/10 703 6.5 - S/D Gravel - - 6 2U1401/10 415 5.5 - PenMac Gravel - - 6 2U1401/20 813 5.8 - PenMac Gravel - - 6 2U1401/30 419 6.0 - PenMac Gravel - - 6 2U1503/10 339 5.8 - S/D Gravel - - 6 2U1504/10 335 5.5 - S/D Gravel - - 6 2U2101/10 266 5.4 - S/D Gravel - - 6 2U2102/10 234 6.0 - S/D Gravel - - 6 2U2103/10 246 5.8 - S/D Gravel - - 6 TOTAL 9,617 33 7 . 3 Two types of forecast commonly produced by planning systems are those for road conditions and budgets. An example of a road condition forecast is shown as a tabular output in Box 7.1 and graphically in Box 7.2. The example indicates the effect over a ten-year period of a fixed budget level on the surface and structural condition indices of Class B roads and unclassified roads. The tabular output form is of more general use, enabling reports to be produced on indices of four types of road. Analysis can also demonstrate the effect of different budgets being specified for different years. With the particular maintenance and priority regimes adopted in this example, road conditions are predicted to decline over time. Structural conditions will deteriorate more rapidly than surface conditions, perhaps reflecting a maintenance policy which focuses on surface treatment rather than structural repair. Note also the predicted acceleration of structural deterioration in the second half of the projection period. 7 . 4 Boxes 7.3 and 7.4 show examples of typical outputs from an analysis which determined the annual budget necessary over a ten-year period to ensure that the surface and structural condition of the network remained unchanged. In this example, budget levels would need to rise steadily over the first part of the projection period, and slightly more rapidly over the second period. This reflects the deteriorating structural condition illustrated in Boxes 7.1 and 7.2. The budget figures normally used in such outputs are stated at constant prices, with no allowance for inflation. 7.1 Planning systems assist in the strategic management of the road network. For example, a planning system might be used to help determine appropriate treatment standards for the various road hierarchies within the network, so as to minimise the life cycle costs of road construction and maintenance and reduce road user costs; or to help examine the likely effects of different budget levels on future road conditions. Figure 7.1 summarises the management cycle of decision- making for these typical applications. Planning systems are used for analysis of the entire road network, typically categorised by traffic level and road condition; individual sections are not identified. The likely users of planning systems and their ouputs are noted in Box 5.1. 7 . 2 The outputs of a planning system are likely to include:
Projected annual capital and recurrent budget requirements to meet road administration standards over a user-defined period into the future
Projected road conditions resulting from the application of pre-defined annual budgets for a user-defined period into the future
Projected road administration costs and road user costs for pre-defined standards, or annual budgets, for a user-defined period
Incremental net present value (NPV) of adopting one set of standards compared with another, or of adopting one particular stream of annual budgets compared with another. 7 Specification of planning systems Network information a) Publish standards b) Publish forecast of budget needs Review forecasts prior to start of next planning cycle Review planning procedures Determine a) Standards that minimise costs b) Budgets that support standards Surveys of aggregate network condition for periodic and reactive worksand historical data for cyclic works a) Apply cost rates to give budgets, with prioritised treatments b) Apply cost rates to give budgets, but no no prioritisation a) Treatments determined by applying a range of standards to give a range of budgets b) Treatments determined by applying fixed standards Figure 7.1 Example applications of planning systems works and historical data 34 Box 7.1 Example of output of projected road condition for given budget PLANNING SYSTEM PROJECTED ROAD CONDITION FOR GIVEN BUDGET PAGE 1 LEAGRAVE DISTRICT DATE: 01-APR-97CLASS A CLASS B CLASS C UNCLASSIFIED YEAR BUDGET SURF STRUCT SURF STRUCT SURF STRUCT SURF STRUCT CI CI CI CI CI CI CI CI 1998 20,000 - - 3.48 3.70 - - 3.41 3.17 1999 20,000 - - 3.47 3.68 - - 3.40 3.14 2000 20,000 - - 3.49 3.67 - - 3.40 3.09 2001 20,000 - - 3.48 3.63 - - 3.38 3.07 2002 20,000 - - 3.46 3.58 - - 3.34 3.01 2003 20,000 - - 3.45 3.51 - - 3.35 2.95 2004 20,000 - - 3.43 3.46 - - 3.32 2.89 2005 20,000 - - 3.40 3.39 - - 3.32 2.86 2006 20,000 - - 3.41 3.30 - - 3.29 2.78 2007 20,000 - - 3.41 3.19 - - 3.28 2.70 7 . 5 Because a key purpose of planning systems is to illustrate trends, graphical outputs are particularly useful. The graphs in Boxes 7.2 and 7.4 could be shown as histograms. Other types of graphical outputs can be produced. For example, pie charts are a useful medium for communicating proportional data about the road network, perhaps indicating different types of construction, or sections in different states of repair. A good planning system should be sufficiently versatile to offer the user a range of possible graphical presentations. 7 . 6 The data used in planning systems normally cover the entire road network at a coarse level, probably IQL-IV (Table 5.3). Table 7.1 lists the information groups likely to provide data for a planning system. 7 . 7 The models required by a planning system will depend on the details of the applications involved. Those required by the two applications used as examples would probably include the following: Traffic growth: Models for traffic growth normally require data grouping by vehicle class. Ranges of existing traffic levels are required, and future traffic is normally based on simple percentage growth rates for each class of vehicle. Loadings are modelled in terms of equivalent standard axles for the purposes of pavement design and strengthening, and in terms of mean gross vehicle mass for the purpose of bridge design. Road deterioration : Predictions of road deterioration are needed for the projection of conditions into the future, and for projecting historical condition data to present-day values when current information is not available. The various models are normally based on an analysis of past trends, using either deterministic or probabilistic methods. A range of mathematical formulations is available for this purpose. Treatment selection : Models for treatment selection are used to decide appropriate works to correct road defects, reflecting the judgement of a practising engineer. They are often termed ‘treatment selection rules’. The methods available are typically defined in terms of matrices of the various parameters that affect the treatment selected, or in the form of decision trees. 35 Box 7.3 Example of output of budget required to maintain condition PLANNING SYSTEM BUDGET REQUIRED TO MAINTAIN CONDITION PAGE 1 LEAGRAVE DISTRICT DATE: 01-APR-97CLASS A CLASS B CLASS C UNCLASSIFIED YEAR BUDGET SURF STRUCT SURF STRUCT SURF STRUCT SURF STRUCT CI CI CI CI CI CI CI CI 1998 20,000 - - 3.48 3.70 - - 3.41 3.17 1999 21,367 - - 3.48 3.70 - - 3.41 3.17 2000 24,173 - - 3.48 3.70 - - 3.41 3.17 2001 25,282 - - 3.48 3.70 - - 3.41 3.17 2002 27,248 - - 3.48 3.70 - - 3.41 3.17 2003 28,728 - - 3.48 3.70 - - 3.41 3.17 2004 32,520 - - 3.48 3.70 - - 3.41 3.17 2005 34,745 - - 3.48 3.70 - - 3.41 3.17 2006 37,018 - - 3.48 3.70 - - 3.41 3.17 2007 39,522 - - 3.48 3.70 - - 3.41 3.17 Box 7.2 Example of graphical output for projected road condition for giv en budget 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2.6 2.8 3 3.2 3.4 3.6 3.8 Class B: surface Class B: structure Unclass: surface Unclass: structure Condition index 36 Table 7.1 Information groups likely to be used in planning systems ElementAspects Data used for planning (IQL-IV) Examples of data Road inventory Network Yes Proportion of network meeting given criteria Location N o – Geometry Yes Geometry ranges Furniture No – Environs Depends on application – Pavement Structure Yes Strength category Condition Yes Condition summary (serviceability index) Structures Inventory Depends on application – Condition – Traffic VolumeYes AADT range Loadings Yes Regional average ESA per heavy vehicle Accidents Depends on application – Finance Costs Yes Global costs Budgets Yes Sub-sector budgets Revenues Depends on application – Activity Projects No – Interventions No – Commitments Yes Long term budget commitments Resources Personnel No – Materials No – Equipment No – Notes: ESA = Equivalent standard axles See Appendix C for further details of data examples Box 7.4 Example of graphical output of budget required to maintain condi tion 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 15,000 20,000 25,000 30,000 35,000 40,000 45,000 Budget 37 Box 7.5 Prioritisation methods Methods based on treatment choice Priorities are related to treatment type and road hierarchy or importanc e. The methods recognize that some treatments are more cost-effective than others if applied at t he right time. They have modest requirements in terms of data and computation time. Overseas Road Note 1 includes an example of this approach. Cost-effectiveness methods Priorities are related to the ‘cost-effectiveness’ ratio of treatm ent life to treatment cost. These methods reflect the higher value of a treatment which lasts longer. They too can be relatively modest in terms of data and computational effort. Optimisation methods The optimum combination of a number of different works options is select ed to achieve a given objective, which might be to minimise the life cycle costs on the networ k or to maximise the quality of road condition. Costs normally include both road administration and r oad user costs. These methods provide solutions based on a long-term view of the network, but are demanding in terms of data and computational effort. One example of this approach is the Ex penditure Budgeting Model (EBM) used in conjunction with HDM-III. Reduced time period analysis methods These methods address the theoretical concern that life cycle optimisati on methods base their decisions on long-term predictions which might turn out to be inaccurate . For example, budgets may change from those predicted, or traffic levels and road conditions m ay differ significantly from those projected. This type of method addresses these concerns by basing decisions on a limited time period of analysis. Their performance is similar to that of optimis ation methods, but they are less demanding in terms of data and computational resources. Prioritisation: A number of models are available for setting priorities when budgets are constrained. These models offer varying levels of sophistication, require different amounts of data and computation time, and produce recommendations that differ in terms of their impact on the longer-term condition and works requirements for the network. Methods which relate priorities principally to the severity of road condition are not recommended, since they tend to lead to conditions that worsen over time and to increasing works cost requirements. Other methods have the characteristics shown in Box 7.5. Where road user cost and pavement performance models are used, treatments can be prioritised only for the road pavement itself. Off-road defects cannot normally be prioritised with models involving concepts of treatment life. The choice of model will therefore depend on the feature being prioritised, as well as on the ability of the road administration to satisfy the data and computational requirements of the various methods. 7 . 8 Various planning models used in road management are described in Road maintenance management: concepts and systems (Robinson and others 1998). 38 8 Specification of programming systems 8 . 1 Computer-based programming systems are used in the short to medium-term planning of road management: they serve a tactical role as distinct from the strategic role played by planning systems. In their most common application, they help decide which road sections are likely to warrant treatment in the next budget period, and they assist in prioritising treatment by indicating the best combination of options that can be funded within budget constraints. Figure 8.1 shows the management cycle for this application. These systems are used also to produce rolling programmes of work, typically for three to five-year time horizons. Programming is performed on road sections across the entire network. The likely users of programming systems and their outputs are noted in Box 5.1. 8 . 2 The outputs of a programming system are likely to include:
List of sections, in priority order and in section order, showing recommended treatments and costs that can be funded in the budget year under pre-defined capital and recurrent budget constraints. It should be possible for the user to work interactively with these lists so as to amend treatments, costs and the order of projects in the priority list.
List of user-selected sections, in section order, showing conditions and recommended treatments.
List of user-selected sections, in section order, showing traffic, axle loading and road user costs. Network information Submit works programme Review programme prior to start of next programming cycle Review programming procedures Determine work programme that can be carried out with next year's budget Cost rates applied and options prioritised to produce programme within budget Needs assessed by comparing condition with standards for periodic and reactive works, and historical data for cyclic and special works Works options that are available to restore condition to standards are determined Figure 8.1 Example application of a programming system
Projected rolling programme of work over a three-year period, reflecting any user modifications to the list of sections to be treated. 8 . 3 Box 8.1 shows a specimen output for all sections in the network, summarising condition, and indicating recommended treatments and costs. Sections are listed in label order. Section lengths are also shown to help relate the scale of costs to the work to be done. Various methods of summarising condition can be used: in this particular example, condition indices are quoted for road surface, pavement structure, road edge and shoulders. Outputs from programming systems often show the priority index against each section where treatments have been recommended. 8 . 4 Treatments recommended by the system are generic. Since relatively coarse data are used for this network-level analysis, it is not normally possible to design detailed treatments; these are produced instead at the preparation stage. For example, the ‘Olay’ treatment is a generic overlay, and no recommendation is made at this time about its thickness or composition. Similarly, the treatment costs too are generic. Because it is necessary to plan for uncertainty prior to detailed design, 20 per cent more treatments than can be funded are usually taken forward to the preparation stage. Treatments and costs are then refined, allowing the final programme to be confirmed. 39 Box 8.1 Specimen output for section treatments and costs PROGRAMMING SYSTEM SECTION TREATMENTS AND COSTS PAGE 1 LEAGRAVE DISTRICT DATE: 01-APR-9 SECTION LENGTH SURF STRUCT EDGE SHOULD C/WAY SHOULD LABEL (m) CI CI CI CI TREATMT TREATMT COST B486/20 603 3.8 3.5 4.2 4.1 - - 0 B486/30 1,750 4.2 3.6 4.3 3.4 - - 0 B488/10 1,023 2.7 3.8 4.3 2.8 S/D Patch 14,065 B488/10 491 3.2 3.9 3.9 3.7 - - 0 2U164/10 960 3.6 3.9 4.2 4.0 - - 0 2U210/10 823 2.8 3.2 3.0 3.5 S/D - 9,876 2U245/10 1,166 1.9 3.0 3.6 3.2 Patch+S/D - 16,324 2U257/10 437 4.6 2.6 2.9---0 2U258/10 197 4.2 3.4 3.1---0 2U259/10 2,264 3.7 3.0 3.4 3.8 - - 0 2U355/10 703 3.8 3.9 3.6---0 2U1401/10 415 4.2 2.9 2.8---0 2U1401/20 813 4.3 3.3 2.7---0 2U1401/30 419 4.0 3.8 3.0---0 2U1503/10 339 2.9 1.9 2.5 - Olay - 14,238 2U1504/10 335 3.5 2.7 3.3---0 2U2101/10 266 4.2 3.5 2.7---0 2U2102/10 234 1.7 3.6 2.4 - Patch+S/D - 3,276 2U2103/10 246 1.8 2.8 2.8 - Patch+S/D - 3,444 TOTAL 13,484 3,831 1,023 61,223 8 . 5 Box 8.2 lists sections where treatments have been identified, in priority order. In many instances the priority index (for instance, cost/benefit ratio) might also be shown. It is normal to indicate cumulative costs in this type of output so as to make it clear when the budget cut-off has been reached. In the example set out in Box 8.2, the road engineer has been working interactively with the system to select projects from those recommended for inclusion in the programme. The selected projects are shown in the final column. Since the available budget is no more than 20 000, it will not be possible to fund theprojects ranked second and third, and the engineer has selected the projects ranked in 4th and 5th place to complete the programme. 8.6 Data will typically be at level IQL-III/IV (Table 5.1). The information groups from which data are likely to be needed are shown in Table 8.1. 8.7 The models required by programming systems are similar to those used in planning systems. The comments made in Chapter 7 are applicable also to programming systems. 40 Box 8.2 Specimen output for section priority list PROGRAMMING SYSTEM SECTION PRIORITY LIST PAGE 1 LEAGRAVE DISTRICT DATE: 01-APR-97SECTION LENGTH C/WAY SHOULD CUM USER PRIORITY LABEL (m) TREATMT TREATMT COST COST SELECT 1 B488/10 1,023 S/D Patch 14,065 14,065 14,065 2 2U245/10 1,166 Patch+S/D - 16,324 30,389 - 3 2U210/10 823 S/D - 9,876 40,265 - 4 2U2102/10 234 Patch+S/D - 3,276 43,541 17,341 5 2U2103/10 246 Patch+S/D - 3,444 46,985 20,785 6 2U1503/10 339 Olay - 14,238 61,223 – Table 8.1 Information groups likely to be used in programming systems ElementAspects Data used for programming (IQL-III/IV) Examples of data Road inventory Network Yes Determination of sub-network likely to be treated Location Yes Sections Geometry Yes Widths, curvatures, rise and fall, etc. Furniture No – Environs Depends on application – Pavement Structure Yes Structural number Condition Yes Condition summary (serviceability index) Structures Inventory Depends on application – Condition – Traffic VolumeYes AADT range and seasonal factors Loadings Yes Section average ESA per heavy vehicle Accidents Depends on application – Finance Costs Yes Unit costs Budgets Yes Capital and recurrent budgets Revenues No – Activity Projects Yes Projects likely to be funded Interventions Yes Maintenance interventions likely to be funded Commitments Yes Budget commitment for next year Resources Personnel No – Materials No – Equipment No – Notes: ESA = Equivalent standard axles Appendix C provides further details of data examples 41 9 Specification of preparation systems a more detailed condition assessment of a project selected for potential funding. The output provides information on the locational, geometric and structural features of the section, and summarises at 100m intervals the condition measurements for a range of parameters. In this example, the areas of cracking and ravelling have been recorded, as have the number of pot-holes, the length of deteriorated edge on each side of the road, and the depth of ruts. Though the output includes a column for deflection measurements, none have been recorded on this section, perhaps because the parameter was considered inappropriate for a Class B road. The final column indicates roughness results. Data such as those recorded in the example provide the road engineer with valuable background information when designing or verifying specific treatments. 9.4 Box 9.2 shows an interactive treatment design application, related to surface dressing The output states that the design has been undertaken using the method described in TRL Overseas Road Notes 2 and 3 (TRL, 1982, 1985). The road length and width are obtained from the road inventory and are used to calculate the area to be treated. The engineer has worked interactively with the system and entered certain data: the system has then computed the design implications. The interactive process continues until the engineer is satisfied with all aspects of the design. During this process, the 9 . 1 Preparation systems perform a variety of road management tasks at the stage when works are being packaged for implementation. Typical applications include the detailed design of works or treatments, and the letting of contracts or issue of work instructions. Figure 9.1 shows the management cycle for these applications. In this stage, detailed site investigations may be undertaken, detailed specifications, quantities and costings are likely to be determined, and any cost- benefit analysis that formed part of the r equirements phase (4.7-4.11) is reviewed to confirm the feasibility of the final works. In addition, preparation systems may be used in contract packaging to combine works from adjacent or near-by sections into projects of a size that is cost- effective for works execution. This category of system operates at the road section level. The likely users of preparation systems are noted in Box 5.1. 9.2 The outputs of a preparation system are likely to include:
Detailed design information.
Work packages.
Works orders for projects, including bills of quantities. 9 . 3 Three examples illustrate these outputs. The first, shown in Box 9.1, includes the results of Network information Review or check design or contract or work instruction Review design procedures a) Undertake design b) Prepare and let contracts or issue work instructions a) Design of works b) Issue of contract or work instruction a) Cost rates applied and priorities reconfirmed b) Bill of quantities prepared a) Design options determined b) Options for specification determineda) Assessed by detailed surveys and condition compared with standards for periodic works b) Appropriate form of contract or work instruction selected Figure 9.1 Example applications of preparation systems 42 engineer would have access to condition data, as shown in Box 9.1, and to other information stored in the system – for example, on traffic volumes, accidents, or sources of materials. 9.5 The output shown in Box 9.2 has been obtained in the following way. Under the heading of ‘chippings’, the engineer has entered the road surface type and the lane traffic category, and the system has determined that 10mm chippings are required with an application rate of 14kg/m 2. Normally, for each input value, the engineer would be able to call up from the system the allowable range of possible inputs to assist with the selection. Under ‘bitumen’, the engineer has entered the traffic constant, the existing surface, type of chippings, and the climate. The system has used a ‘look-up table’ to determine the design constants relevant to each of these characteristics; the engineer has then entered the road surface temperature and, using all of these values, the system has determined the grade and the application rate of the bitumen. The total quantities of both chippings and bitumen required for the section are then calculated by the system. 9.6 Box 9.3 offers a third example, which shows a bill of quantities for surface dressing produced by the system. The engineer has decided to combine the works on the three sections selected at programming stage into one contract package, which is reflected in the bill of quantities. The preparation system has to include a library of works items to enable these outputs to be produced. 9.7 The data required for preparation applications are likely to be quite detailed, but related only to a few individual sections. They will Box 9.1 Example of output showing condition assessment PREPARATION SYSTEM CONDITION ASSESSMENT PAGE 1 SECTION: B488/10 Leagrave Road from 50km/h limit to Weltmore Rd DATE: 01-SEP-97 SECTION LENGTH C/WAY SHOULD C/WAY C/WAY C/WAY SHOULD TRAFFIC LABEL (m) WIDTH(m) WIDTH(m) SURF BASE SUB-BASE CONSTRN CLASS B488/10 1,023 7.0 1.0 S/D Crsh stn Gravel S/D 3 CONDITION CRACKS RAVEL POT- EDGE L EDGE R RUT DEFL ROUGH CHAINAGE (m2) (m2) HOLES (lin m) (lin m) (mm) (mm/100) (m/km) 0 + 100 36 0 0 0 0 6 - 2.4 0 + 200 41 0 0 0 0 8 - 2.6 0 + 300 38 0 0 10 0 4 - 2.9 0 + 400 46 5 0 100 0 3 - 2.8 0 + 500 32 3 0 40 0 6 - 3.2 0 + 600 36 0 0 0 0 5 - 2.9 0 + 700 31 0 0 0 0 8 - 3.2 0 + 800 48 6 0 30 0 7 - 3.3 0 + 900 32 7 0 0 0 4 - 3.0 1 + 000 34 2 0 0 0 8 - 2.8 1 + 023 8 0 0 0 0 4 - 2.7 TOTAL/AVG 382 23 0 180 0 5.9 0 2.9 PER CENT 5.3 0.3 0 - 0 - - - 43 probably be at the IQL-II/III level. The information groups from which data are likely to be needed are listed in Table 9.1. 9 . 8 Where preparation systems are used to assist with the preparation and letting of contracts, one item of data that may be needed is the type of contract to be applied. Standard forms of contract, such as those produced by FIDIC and the New Engineering Contract, are normally used for road works but local forms also may be in use. It is beyond the scope of this Note to enumerate the various types of local forms: in these instances, data may also include standard bill of quantity items required for different works, libraries of costs, suppliers of materials, and approved contractors.9 . 9 Typical models required by preparation systems include: Traffic growth (as described in relation to planning systems). Road deterioration (as described in relation to planning systems). Works design : Models used for this purpose will be standard design methods for activities such as surface dressing, pavement and overlay design, and geometric design. Some of these models may be available as computerised systems, either integrated into the road management systems, or produced as stand-alone systems. Box 9.2 Example output for interactive treatment design PREPARATION SYSTEM INTERACTIVE TREATMENT DESIGN PAGE 1 SECTION: B488/10 Leagrave Road from 50km/h limit to Weltmore Rd DATE: 01-SEP-97 TREATMENT: Surface dressing METHOD: Overseas Road Note 2/3 LENGTH (m): 1,023 WIDTH (m): 7.0 AREA (m2): 7,161 CHIPPINGS BITUMENCONSTANT ROAD SURFACE TYPE: Hard TRAFFIC CONSTANT: Medium heavy -1 LANE TRAFFIC CATEGORY: 3 EXISTING SURFACE: Average bituminous -1 CHIPPING SIZE (mm): 10 TYPE OF CHIPPINGS: Cubical 0 CLIMATE: Temperate 0 TOTAL: -2 SURFACE TEMP (deg C): 30 BITUMEN GRADE: MC3000 APPLICATION RATE (kg/m2): 14 APPLICATION RATE (kg/m2): 1.0 QUANTITY (kg): 100,254 QUANTITY (kg): 7,161 44 Box 9.3 Example of output from a bill of quantities PREPARATION SYSTEM BILL OF QUANTITIESPAGE 1 DATE: 01-MAR-98 DESCRIPTION OF WORKS: Surface dressing JOB NO: LGV/R/98/034 SECTIONS LENGTH WIDTH AREA 1 B488/10 Leagrave Road from 50km/h limit to Weltmore Rd 1,023 7.0 7,161 2 2U2102/10 Balcombe Road from May Ave 234 6.0 1,404 3 2U2103/10 West Street from health clinic to Limbury Path 246 5.8 1,427 TOTAL 1,503 9,992 ITEM QUANTITY UNIT RATE TOTAL 1 Place signs and traffic control devices 3 Sum 2 Repair pot-holes and edge damage Nil Sum - - 3 Spray MC3000 bituminous binder at a rate of 1.0kg/m 2 9,992 m 2 4 Spread 10mm cubical aggregate at a rate of 14kg/m 2 and roll until embedded with rubber-tyred roller 9,992 m 2 TOTAL 45 Table 9.1 Information groups likely to be used for preparation systems ElementAspects Dat a used for preparation (IQL-II/III) Examples of data Road inventory Network No – Location Yes Section or groups of sections Geometry Yes Geom etry elements Furniture Yes As required by the project Environs Yes As required by the project Pavement Structure Yes Summary of data for individual layers Condition Yes Individual defects Structures Inventory Yes As required by the project Condition Yes As required by the project Traffic Volume Yes AADT by principal seasons Loadings Yes Average ESA per vehicle class Accidents Depends on application – Finance Costs Yes Unit costs Budgets Yes Project budget Revenues No – Activity Projects Ye s Project being designed/contracted Interventions Yes Maintenance works being designed/contracted Commitments No – Resources Personnel No – Materials No – Equipment No – Notes: ESA = Equivalent standard axles Appendix C provides further details of data examples 46 Network information Undertake works activity Extent and quantity of works assessed from detailed inspections for periodic and reactive works, and from standards for cyclic works Review achievement against target Review procedures for managing works activities Undertake and supervise work Apply targets, and labour, equipment and materials resource requirements from standardAppropriate performance standard selected for activity Figure 10.1 Example application of operations system 10 Specification of operations systems
Annual cost summary by road section, activity and budget head, with totals. 1 0 . 4 Performance standards are used to ensure quality and consistency when managing operations. The example in Box 10.1 sets down the basic procedures for an individual activity, in this instance surface dressing. It includes a method statement, and defines resource requirements, costs and the expected productivity. Performance standards of this type should form part of the road administration’s quality management system. They will need review and updating to reflect changes in costs or the introduction of modified work practices. 1 0 . 5 Performance standards can be used as the basis for issuing work instructions. Some systems combine the two documents by showing target output, and providing a box where the work achieved can be entered by the supervisor or foreman. This information is needed by the system to enable performance to be monitored over time. Inclusion of both pieces of information on the same form simplifies data entry into the system, and ensures that those involved are aware of any shortfall in performance. Recording information in this way allows weekly, monthly and annual summaries to be produced for monitoring purposes. 1 0 . 6 Box 10.2 shows a weekly staff time summary. The information is produced directly from time sheets which need to be completed daily. These can either be paper-based, or maintained in electronic form, with staff entering details directly into the system. The weekly staff time summary can feed into the staff payment system and into progress and performance monitoring systems. 1 0 . 1 Operations systems assist with the management of on-going activities, supporting decisions that are typically made on a daily or weekly basis. Operations are focused on individual sections or sub-sections of road: typical tasks include work scheduling; monitoring the use of labour, equipment and materials; and recording completed work. Figure 10.1 shows the management cycle for a typical application. In addition, operations systems may contribute to cost accounting and financial management, equipment management and facilities management. 1 0 . 2 A road administration will need an operations system only if it has in-house works units. Where work is contracted out, it is the contractor who is likely to need to use operations systems. In this case, operations management by the road administration becomes a matter of project management: since computer-based systems for project management are widely available and their use is already well documented, they are not included in the scope of this Note. Typical users of operations systems are noted in Box 5.1. 1 0 . 3 Operations systems are likely to have the following outputs:
Performance standards for works, defining the minimum requirements and specification for activities, and including schedules and costs for equipment, materials, and labour.
Work instruction/accomplishment.
Weekly labour time summary by person and budget head.
Weekly cost summary by activity and budget head, with totals. 47 Box 10.1 Sample output of a performance standard OPERATIONS SYSTEM PERFORMANCE STANDARD Revision C: 01 April 1997 Page 1 of 1WORKS ITEM CODE: LG-112 DESCRIPTION: Single surface dressing DEFINITION Application of one coat of surface dressing consisting of a layer of bituminous binder on prepared surface covered by a layer of stone chippings RESTORATION STANDARD Uniform appearance with stone to stone contact RELEVANT SPECIFICATION LGS 11.22, LGS 11.34 - 11.37 UNIT OF MEASUREMENT m 2 AVERAGE DAILY PRODUCTION 2 000 m 2 WORKS METHOD 1) Establish traffic control - refer to Roadworks Signing Guide 2) Inspect pavement and mark out all areas of repairs if this has not already been done 3) Repair potholes and edge damage (see LG-008 and LG-009) 4) Remove all loose material with hand or mechanical brooms 5) Confirm and check all plant is working before commencing surfacing operation 6) Apply bitumen using distributor ensuring even spread (confirm rate of 1.0kg/m 2 with Supervisor) 7) Spread aggregate uniformly (confirm rate of 14kg/m 2 with Supervisor) 8) Roll to embed aggregate with 8-10 tonne rubber-tyred roller or other approved plant 9) Brush to remove surplus aggregate using mechanical broom or manually 10) Remove traffic control, leaving loose chipping warning signs if necessary ESTIMATED ITEM COST LABOUR NUMBER RATE AMOUNT Foreman/Supervisor 1 195.00 195.00 Operator 5 150.00 750.00 Semi skilled labourer 2 135.00 270.00 Labourer 6 125.00 750.00 EQUIPMENT Bitumen distributor 1 375.00 375.00 Road roller (8/10t) 1 400.00 400.00 Loading shovel (1.5m 2) 1 550.00 550.00 Tipper truck (5/10t) 1 410.00 410.00 Gritter 1 100.00 100.00 Signs and traffic control 1 50.00 50.00 Mechanical broom 1 200.00 200.00 MATERIALS UNIT QUANTITY 10mm aggregate tonne 28.0 25.50 714.00 MC3000 bitumen kg 2000.0 0.24 480.00 Diesel litre 25.0 0.91 22.75 TOTAL 5266.75 ESTIMATED UNIT RATE 2.63 48 1 0 . 7 A key aspect of operations systems is that they allow monitoring of both achieved output and cost. Weekly monitoring (sometimes extended over fortnightly intervals) is necessary in most situations to avoid under-achievement and cost over-runs escalating out of control. Weekly reports can be produced for activities under all budget heads showing target and actual output and expenditure, under the headings of labour, equipment and materials. Spend-to-date and remaining budget should also be shown. Similar reports are normally produced on an annual basis, typically for costs by activity and section. All of these reports can be produced automatically from weekly work achievement returns. 1 0 . 8 Box 10.3 provides an example of a report for an annual cost summary. It relates to the capital budget allocation for a district, and is disaggregated by activity codes. This example shows annual targets and actual outputs, with the percentage achievement for each activity. Costs are disaggregated by labour, equipment and materials. For each activity code, the budget and actual expenditure are shown, with the percentage spend against budget.1 0 . 9 This particular example indicates that there was under-performance for Activities 04021 and 04024, with low productivity and an over-spend of budget. The reasons for this would need to be investigated by the engineer, though the problem would have been apparent from the monitoring reports produced through the year which give an opportunity for more speedy remedial action. For Activity 04025, the budget figure was met with a 32 per cent increase in productivity. For Activity 04029, there was 24 per cent over-production at a cost of only 43 per cent of the budget, suggesting that the targets set for the activity were low. Information fed back from outputs such as this provide a sound basis for investigating specific problems affecting individual activities or sections, and defining more realistic targets for the following year. 10.10 The data required for operations management are likely to be highly detailed – probably IQL-I/II – but they will apply only to a short length or sub-section of road. Table 10.1 lists the information groups from which data are likely to be needed for operations systems. Box 10.2 Sample output for weekly staff time summary OPERATIONS SYSTEM WEEKLY STAFF TIME SUMMARY PAGE 1 LEAGRAVE DISTRICT WEEK ENDING Sunday 12 April 1998 TOTAL HOURS CODE NAME STANDARD TIME TIME AND A HALF DOUBLE TIME 321 R Baynham 40 0 0 342 B McNally 40 0 0 353 K Hawkes 0 0 0 344 J Groves 40 6 8 305 S Owen 32 0 0 346 D Pacey 40 0 0 377 W Bingham 40 6 8 368 A Brown 40 6 8 309 R Morton 0 0 0 310 G Cummins 16 0 0 311 A Gregory 40 0 0 CHECKED....................... DATE......................19..... 49 Box 10.3 Sample output for annual cost summary OPERATIONS SYSTEM ANNUAL COST SUMMARY (ACTIVITIES) PAGE 1 LEAGRAVE DISTRICT BUDGET HEAD: 04 (CAPITAL) YEAR 1997ACCOMPLISHMENT COST ACT CODE TARGET ACTL VAR % LABOUR EQUIP MATLS BUDGET ACTL VAR % 04021 36,298 32,157 89 6,219 12,458 8,312 25,000 26,989 108 04024 42,135 38,296 91 4,564 36,744 2,635 40,000 43,943 110 04025 860 1,134 132 368 7,345 2,451 10,000 10,164 102 04028 0 0 - 0 0 0 0 0 - 04029 13,157 16,273 124 987 2,197 1,137 10,000 4,321 43 TOTAL - - - 12,138 58,744 14,535 85,000 85,417 100 Table 10.1 Information groups likely to be used for operations systems Data used for Element Aspects operations (IQL-I/II) Examples of data Road inventory Network No – Location Yes Sub-sections where work is being undertaken Geometry Yes Detailed geometry of sub-section Furniture Yes As required by the project Environs Yes As required by the project Pavement Structure Yes Detailed data for individual layers Condition Yes Extent and severity of individual defects Structures Inventory Yes As required by the project Condition Yes As required by the project Traffic Volume Yes Short term flows Loadings No – Accidents Depends on application – Finance Costs Yes Operational costs Budgets Yes Project budget Revenues No – Activity Projects Ye s Project being designed/contracted Interventions Yes Maintenance works being designed/contracted Commitments No – Resources Personnel Yes Staff resources from performance standard Materials Yes Materials resources from performance standard Equipment Yes Equipment resources from performance standard Notes: Appendix C provides further details of data examples. 1 0 . 1 1 While the recommendations derived from operations systems tend not to be based on the use of models, and it is unusual for these systems to include models, their outputs are used to support decisions made by users. For this reason, operations systems can properly be regarded as decision-support systems. 50 11 Computer requirements Sources of procurement 11.1 Earlier comments on the use of manual techniques are reiterated here (see 2.9). However, once the decision has been taken to adopt a computerised approach, hardware and software requirements need to be addressed. Road administrations are often keen to develop their own in-house software for proposed road management systems. Sometimes a ‘not-invented- here’ attitude leads to a reluctance to use proprietary products, or to adopt systems that are widely used elsewhere. But the systems discussed in this Note may have to manage substantial volumes of data: unless highly efficient software is applied to this task, their running costs can be extremely high. Few road administrations have the competence in software development to produce for themselves systems that will be powerful and efficient enough to perform successfully. In most cases, procurement and customisation will offer the most economical solutions. 1 1 . 2 Any software product for use in road management has to be robust and dependable, particularly where large databases are involved. Some of the computer applications that are commercially available do not meet these criteria. For this reason, administrations need to assess rigorously the viability of the software and the competence of its supplier before committing themselves to its procurement. Customisation 1 1 . 3 Any proprietary product that is worth buying has to offer, above all else, the potential for customisation to meet the precise needs of the purchaser. This factor should in large measure determine the choice of software to be adopted. Some software products are designed in a flexible way and need to be customised before use by setting parameter values known as ‘meta data’. Though the process of customisation can be undertaken by the road administration itself, it will normally be more economical to have the system supplier do this. Less flexible software can be customised only by the supplier changing the software code, which is likely to prove more expensive than customising parameter-based software. Some software is designed in such a way that anything other than superficial customisation is impossible. Modular approach to software 1 1 . 4 The most efficient and flexible solution for software procurement is normally the adoption of a modular software structure, which achievesintegration through a common data bank. This modular structure has to reflect the administration’s road management procedures as grouped into functions and tasks. Some proprietary systems fail to match adequately the needs of an administration because they lack the potential for modularity. 11.5 The road information system or data bank, which provides the core of the road management system, requires a network referencing system around which is built an inventory of the road network to which all other information can be related. Figure 11.1 depicts this modular framework, which includes data items from the information groups listed in Table 5.1 and the five types of information and decision-support systems identified in this Note (2.11). An integrated approach of this kind has to be a long-term aim. In the short to medium-term, most road management systems may contain only part of the framework, so the software that is procured needs to be flexible enough to accommodate future change and growth. Programs and databases 11.6 The modular framework shown in Figure 11.1 is implemented through a series of application programs operating in conjunction with a database. Application programs are needed for input, output and processing (models). All management information required for decision-making is held centrally, while data and technical processing may be decentralised. The structure allows the flow of information between modules to be controlled, so that data are checked to ensure quality and consistency before being used by other modules. 11.7 Ideally, the functions of the core database should be built around a relational database management system (RDBMS), preferably using fourth generation (4GL) programming languages. Applications programs can be written in the same 4GL as the database, or they can interface to the database through what is known as ‘middle-ware’, which is purpose-written software for linking the applications programs to the database. This approach offers two key advantages: first, it allows modules to be procured from a number of different sources at different times; second, it avoids having the road management system tied down to one software vendor through its proprietary RDBMS. For example, a proprietary project management package could be used for work scheduling, with a standard database providing the data storage. The choice of RDBMS will depend on the availability of specialist expertise and the degree of sophistication needed to support the proposed applications. 11.8 The disadvantages of this approach are that considerations of the long term will be dictating 51 short-term actions, so that the initial solution may be more expensive and complicated than a dedicated application, while the development of middle-ware demands sophisticated programming resources which are expensive and may not be available. 11.9 Since the most costly part of any road management system is the data, as noted earlier, it is essential to make sure that any future upgrading of the system is able to use the existing network information. An administration introducing computer-based systems for first time will have most to gain by adopting a simple approach that is in scale with its institutional capability. Once the simple system becomes institutionalised, and as technology advances, the system can be replaced. Providing the system uses an RDBMS or a spreadsheet to store data, it is a relatively straightforward exercise for a computer specialist to transfer these data (possibly after transforming them) to a new, upgraded system. Hardware 1 1 . 1 0 The final decision to be made when planning the implementation of a road management system involves the choice of hardware. This approach – leaving hardware to the last – is in marked contrast to the approach taken in the past by almost all projects to develop and implement computer-based road management systems in non-industrialised countries. 1 1 . 1 1 The choice of hardware will be influenced by the operating system selected, which depends on whether multi-user access to the management system is required. For multi-user access, either a local area network (LAN) or a multi-user operating system such as UNIX will be needed. For single user access, which will be the case in most situations, conventional systems using a Windows operating environment will be sufficient. Trained personnel will be needed to maintain the selected operating system, drawn either from the road administration or from local computing companies under contract. 11.12 Once the requirements for the system software and operating system are defined, the choice of hardware will usually be self-evident. In most instances a microcomputer-based system will be preferred because it allows easy access to hardware maintenance. But the use of workstations should not be overlooked, particularly where large volumes of data will need to be processed, since workstations can substantially improve the efficiency of data storage and operation at little additional cost. 1 1 . 1 3 In all cases, the system has to include adequate facilities to back-up hardware and software in the event of unforeseen failures. Software back-up can be achieved through magnetic or optical devices for the storage of system information and road management data. The minimum requirement for hardware back-up, in the form of un-interruptible power supplies (UPS), is the ability to allow the system to be shut down properly if a power failure occurs. base Processing INPUTS OUTPUTS Road inventory Pavement Structures Traffic Finance Activity Resources Network information Planning Programming Preparation Operation Data Figure 11.1 Modular system framework 52 53 Part C: System operation 54 55 12 Training 12.1 Training improves job performance by extending knowledge, improving skills and modifying attitudes. It enhances the ability of personnel to work in the most economical, efficient and satisfying way to achieve the objectives of the organisation. Training in the operation and use of road management systems has to be viewed against this background. 1 2 . 2 The staff of the road administration will need to receive specific training in the skills that will equip them to work with the management system and make the best use of its outputs. Once the system has been implemented, they will require a continuing programme of further training. If specialist consultants are used to perform the training function, they should concentrate on training counterpart staff who will then be able to undertake future training unassisted. This approach calls for the assignment of consultants and counterparts who are well motivated and who have high levels of interpersonal skills. 1 2 . 3 Detailed guidelines for training are beyond the scope of this Note, but some recommendations on training needs analysis are provided. Training of staff by Thagesen (1996) addresses the subject in more depth. Training needs analysis 1 2 . 4 There is a high degree of correlation between training issues and institutional issues. The institutional appraisal undertaken at the start of the design stage (3.6) should identify clearly the training which the road administration will need to provide to help achieve its objectives. Since the institutional objectives will determine the required training interventions, it is important that no training is planned or implemented without first conducting an institutional appraisal. This will identify any human resource constraints and indicate the necessary remedial measures. 12.5 The training needs analysis and the institutional appraisal should, ideally, be undertaken simultaneously. The training needs analysis, normally based around a structured interview, compares the performance level required from an individual with the level recorded at the time of the analysis. The gap between the two levels indicates the training requirement. In addition to collecting factual information about the individual in terms of qualifications, experience and so forth, the training needs analysis should identify the following points:
Extent of responsibility and authority for - planning, programming, preparation, operations - finance, staff and equipment.
Management skills required.
Computer skills required.
Technical/engineering skills required. 12.6 The analysis is likely to identify requirements for training in excess of the available funding. This means that priorities will have to be set, and this should be undertaken in accordance with cost-benefit principles so that the choice is made to provide the training that will yield the best return on investment. Training levels 12.7 Road management systems include a broad range of applications, while their potential users will possess a variety of skills and backgrounds. For this reason, training has to be approached in a flexible way. The concept of training levels, outlined in Box 12.1, offers a useful means of building flexibility into training provision. As the training level rises from appreciation to ability, there is a corresponding increase required in the depth of knowledge of the systems, but a decrease in the number of potential users. 1 2 . 8 Training courses at one level can assume competence at the preceding levels, so as to keep the training programme focused and avoid repetition. At the first level of ‘appreciation’, training is likely to be more of a dissemination exercise. Much of what is needed at this level would be undertaken at the commitment stage of the system implementation process (3.9). The second and third levels – ‘knowledge’ and ‘experience’ – will relate to the majority of the users of the system, with Level 2 addressing staff whose use of the system is infrequent and Level 3 aimed at regular users. Level 4 – ‘ability’ – will be required by those who have the responsibility for maintaining the system and undertaking other specialist tasks, such as model calibration. Training topics 12.9 Though requirements for preliminary and on- going training will be based on the results of the training needs analysis, it is likely that training needs will be identified in the general areas of:
Management techniques (Box 12.2).
Computer awareness (Box 12.3).
Systems operation (Box 12.4).
Technical matters (Box 12.5). 56 Box 12.2 Course outline: management techniques Target audience: senior staff in the road administration Purpose : to gain an appreciation of basic modern management techniques related to roads, and ensure a clear understanding of the concepts involved as well as the benefits of adopting a more systematic approach to road management Training for these staff is aimed at giving an overview of the road mana gement system and its operation, rather than providing specific technical training related to the system. It is important that senior staff understand fully the system objectives, its functions and its outputs. S pecific aims should include:
Presentation of the general concepts of maintenance management, its impo rtance and potential benefits
Presentation of the organisation and procedures necessary to support the system
Promotion of commitment to ensure effective implementation The training should guide senior staff to react positively toward the be nefits of the new system. There will often be some resistance to setting up a road management syst em within the administration, and this should be addressed. The results of the institu tional appraisal (3.6) will assist in defining needs in this area. Requirements for the provision of resources to co-ordinate, supervise and carry out the tasks and duties involved in operating a road management s ystem will also need to be covered. The training will need to identify any modification to procedur es that may be required as a result of implementing the system. Box 12.1 Training levels Level 1: Broad awareness of the range of applications Less More Appreciation of road management systems in the particular understanding users road administration Level 2: Understanding of some detail of the principles Knowledge involved in the systems used, and how they are applied in practice, including limitations on use Level 3: ‘Hands-on’ experience in the use of the systems Experience for a specific management function Level 4: Detailed understanding and experience of the Ability use of the systems for a variety of applications, with the ability to customise and calibrate systems More Fewer for particular use understanding users 57 Box 12.3 Course outline: computer awareness Target audience: all staff who use computer equipment Purpose : to provide basic information about topics such as software, hardware, operating systems and data security. Subjects that will need to be covered include:
Introduction to computer-based road management systems
Data and its collection, storage and processing
Data security
Software and its common uses
Computer hardware and related devices The intensity of training will be determined by the general level of com puter literacy within the road administration. Box 12.4 Course outline: systems operation Target audience : staff at all levels involved in the operation of the system Purpose : to introduce the capabilities of the system and to demonstrate how it can be used to support the on-going management functions of the organisation The training in this area will be system-specific. The training content should follow the system user guides prepared for the various system components. Box 12.5 Course outline: technical matters Target audience : staff involved in providing technical information to the system Purpose : to understand the techniques of network referencing, inventory collect ion, traffic surveys, collection of data on road condition, and data entry The training content should follow the technical user guides prepared fo r the various system components. The discussion of data (paras 5.12-5.19) and models for co ndition projection, treatment selection and prioritisation may be relevant. 58 12.10 Detailed advice about the content of training courses is outside the scope of this Note. Guidance on training programmes for management, general co- ordination, field engineers and road inspectors is available in a report produced by the OECD (1995). Monitoring training 1 2 . 1 1 To make sure that training objectives are being met, continual monitoring will be required. The results will be used to improve and strengthen the training programme. Monitoring can be undertaken through tests, questionnaires and feedback from participants, as well as performance assessments by personnel responsible for training. These assessments should be made at regular intervals throughout the training. 1 2 . 1 2 Meeting training objectives does not necessarily mean that the road administration’s objectives will be achieved. The road administration may fail to draw on the outputs available or use the new systems; some trainees may not want to share their new knowledge with others. Issues such as these become evident only after training participants have been working for some time in their assigned positions. A post-evaluation is seldom made, but it can be a source of valuable information for the road administration generally, and its findings can be applied specifically in the design of subsequent training programmes. 1 2 . 1 3 It has to be admitted that training has a poor record of success in supporting the implementation and operations management of systems. Emphasis has often been placed on inputs (such as the number of people trained) rather than impacts (such as the effects of training). Training should always be designed to meet clear objectives, with achievement targets that are both manageable and measurable. 59 13 Systems management 13.1Managing the road management system is a function that needs to be treated like any other operational activity undertaken by the road administration. The benefits which a computer-based system can offer, in terms of improved management of the road network, will be lost if this aspect of its operation is neglected. Systems management involves the following sectors of activity:
Defining responsibilities.
Controlling systems and data.
Monitoring and feed-back. Defining responsibilities 1 3 . 2 There are two possible approaches to the operation of a road management system within a road administration. One approach is to make the use of the system widely available throughout the organisation; the other is to concentrate its use inside a specialised unit which supplies system outputs as reports to decision-makers. 1 3 . 3 The first of these approaches has the advantage of developing across the administration a sense of ‘ownership’ of the results, and hence of the system. This is likely to yield long-term benefits since the system will become closely integrated into the operations of the administration. On the other hand, it will incur higher costs – since more staff will need to be trained to run the management system, and more computer hardware will be required – and it will generally take a long time for the benefits to be realised. 1 3 . 4 Operation through a specialised unit allows systems to be introduced more quickly. With activities focused within a small group, fewer people need to be trained in system operation, and hardware requirements will be reduced. The benefits of system use will probably be more immediate, but it will be more difficult to institutionalise the system in the long term. 1 3 . 5 Regardless of the mode of operation, there is usually a need to appoint a system administrator. This person should be a computer specialist who has overall responsibility for the functioning of the system. The responsibilities of the post will include ensuring that the system is running correctly and that operating procedures are adhered to; maintaining data security, access control, back-ups and archiving; issuing passwords; and managing modifications and upgrades to the system. In a central unit responsible for the management system, the system administrator will often be the head of the unit. In an organisation-wide operation, an individual in the Computer Department will usually be an appropriate person to fill the post. 1 3 . 6 When new systems are introduced there may be advantages in starting with a specialised unit, and then extending systems operation more widely within the administration. This approach has attractions in terms of producing both early and longer-term benefits. However, once specialist cells are formed, they often create their own vested interests and are difficult to disband. They may also make the subsequent institutionalisation of the system more difficult because inter-departmental rivalries may develop during the early stages of implementation. The initial institutional appraisal (3.6) needs to examine these options and decide on the best long-term alternative. Control of systems and data User access 13.7 Where the system is intended to be used by many individuals within the administration, controls need to be set up so that different users have access only to the specific applications and data groups that are appropriate to their work. Even where system use is centralised in a specialised unit, access control is no less a requirement because several members of the unit may be working with the system at any one time. 1 3 . 8 Control can take several forms:
Full access with the ability to run applications or to enter and modify data.
‘Read only’ access restricting users to viewing or producing reports.
No access. 1 3 . 9 This control is a basic security feature and will normally be implemented through the use of passwords. It also permits the results of sensitive reports to be viewed only by nominated persons in the administration. Data updating 1 3 . 1 0 Because data become obsolete over time, the management of the system has to include procedures for their updating. Data that change rapidly, such as details of road condition, will need to have an updating regime that reflects the road administration’s management strategy (5.20). For data that change less frequently, such as inventory information, there are two options:
Continuous updating, either as an on-going exercise or as part of the process of condition surveys.
Updating at fixed intervals of time, either for the whole road network or for defined portions of the network on a cyclical basis. 60 1 3 . 1 1 Continuous updating is often preferred on the grounds that the alternative would result in the inventory falling into disrepute. On the other hand it is difficult to capture all inventory changes in this way, and a major periodic updating exercise may still be required. In some instances, a blend of the two options may offer the most practical course of action. Data control 13.12 Data security is achieved by defining and observing strict procedures for regularly backing up the system database. Generally, at least part of the database will need to be backed up each day. Nowadays, hardware is also available to support recovery from the inevitable system crashes and power interruptions. 1 3 . 1 3 The regular archiving of data that are no longer current can help minimise the need for system storage, reduce hardware requirements and increase the speed of database access. Procedures should be introduced which specify archiving functions and define the actions to be taken on those occasions when the archive needs to be accessed. 1 3 . 1 4 Data integrity is often neglected, but is particularly important when databases are used. For example, when changes are made to the physical road network it should not be possible to change section details in the database without also changing all other data relating to that section. The system needs to validate all new data entries to ensure that they are consistent with the data already stored, and that values lie between defined tolerances. Data integrity becomes critical in a system offering multi-user access because more than one user may be working on the data for an individual section of road at the same time. Monitoring and feed-back Institutional issues 13.15 Introducing a road management system can have a significant impact on the institutional arrangements of the administration (see 3.9). For example, the definition of a multi-year programme of works is likely to have implications for the administrative structures, finance, staffing and other resources needed for its preparation and implementation. The required institutional structures need to be in place and functioning as planned from the outset, and typical problems that may need to be addressed include:
Difficulties in financing successful operation of the system.
Difficulties in adapting administrative methods.
Over-estimating the ability to undertake data collection surveys.1 3 . 1 6 Monitoring should provide a check that the policies, objectives, budgetary processes and final works programmes are linked together coherently. There will inevitably be a need to modify system outputs before final implementation owing to the practical realities faced by an administration. Even so, the following questions should be kept under constant review:
Are strategic objectives and desired levels of service being achieved?
Do works programmes reflect the results of the road management system?
Is value-for-money being obtained? 1 3 . 1 7 Failure to address these institutional issues will have technical repercussions (Figure 3.1). For example, the same works implemented at a later date on roads which should have been treated earlier may prove inadequate, and significantly more expensive treatments may be required. In this case it will be necessary to re-examine the administration’s wider maintenance strategies. Technical issues Data 13.18 Implementing a computer-based road management system generally entails large numbers of surveys, measurements and observations. It is essential to maintain up-to-date data (13.10-13.11), otherwise the administration’s perception of the network grows outdated, and the system gradually but inevitably loses credibility, leading to its ultimate demise. 13.19 Updating the database includes the following activities:
Annual or multi-annual surveys collecting monitoring data.
Collecting works records when activities on the road have been completed. Models 1 3 . 2 0 Planning and programming systems, in particular, are likely to include models based on assumptions that may need to be verified. This is critically important in the case of techno-economic models such as HDM-III, even where they are calibrated properly. The consequences of using unverified models include:
Works failing to improve the condition of the road as predicted.
Road sections considered as non-urgent deteriorating more quickly than expected. 13.21 The effects of such disparities may not be apparent in the short term. For this reason a selected sample of the network needs to be monitored in 61 detail to establish differences over time between predicted and observed behaviour (see Box 5.4). In addition, those responsible for maintaining and operating the system need to ensure that the technical methods employed by the system continue to reflect the technical approaches being adopted by engineers and managers in the wider organisation. System operation 1 3 . 2 2 Monitoring the operation of the system is essential if it is to sustain the ability to meet objectives which may alter over time. This final step in the management cycle is an on-going activity, identifying where the system is not meeting requirements and acting as a trigger for action and improvement. 1 3 . 2 3 In some cases the action required may involve minor modification to the system or to the procedures which the system is supporting; but on occasions a more significant system upgrade may be necessary. An upgraded system needs to be subject to the same steps of commitment, requirements, specification and procurement as a new system. The results of all monitoring activities should feed into the process for reviewing the administration’s policy framework. Audit 13.24This provides a physical check, usually on a sample basis, that work has been achieved in conformity with standards and procedures, and that costs and other resources have been accounted for properly. The feedback from road management systems provides a key input to this process. 62 1 4 References Commission of the European Communities (1993). Project cycle management . Brussels: Commission of the European Communities. OECD (1995) . Road maintenance management systems in developing countries . Paris: Organisation for Economic Co-operation and Development. Paterson W D O and Scullion T (1990) . Information systems for road management: draft guidelines on system design and data issues . Infrastructure and Urban Development Department Report INU 77. Washington DC: The World Bank. Robinson R and others (1998) . Road maintenance management: concepts and systems . London: Macmillan. Thagesen B (ed) (1996) . Highway and traffic engineering in developing countries . London: Spon. TRRL Overseas Unit (1987) . Maintenance management for district engineers . Overseas Road Note 1. 2nd edition. Transport Research Laboratory, Crowthorne. TRRL Overseas Unit (1985) . Maintenance techniques for district engineers (2nd Edition) . Overseas Road Note 2. Transport Research Laboratory, Crowthorne. TRRL Overseas Unit (1982) . A guide to surface dressing in tropical and sub-tropical countries . Overseas Road Note 3. Transport Research Laboratory, Crowthorne. TRRL Overseas Unit (1988a) . A guide to road project appraisal. Overseas Road Note 5. Transport Research Laboratory, Crowthorne. TRRL Overseas Unit (1988b) . A guide to bridge inspection and data systems for district engineers . Overseas Road Note 7- Volume 1. Transport Research Laboratory, Crowthorne. 63 Appendix A: Glossary of terms ActivityAny work or intervention that is carried out on the road network. Audit A physical check, usually on a sample basis, that work has been carried out, where specified, to pre-defined standards or procedures, and that costs and other resources have been accounted for properly. Budget head Normal pre-defined headings under which expenditure is allocated by a Ministry of Finance. Capital budget The government budget normally used to fund major projects. Condition index A parameter that combines individual defect measurements to provide a summary indication of defectiveness. Cost-effective The ratio of ‘effectiveness’ to ‘cost’, where effectiveness is a measure of the future value or worth resulting from a decision that is taken, and c ost is the present-day cost of implementing that decision. Cost-benefit analysis A formal comparison of costs and benefits to determine whether or not an investment is worthwhile. Cyclic works Scheduled works whose needs tend to be dependent on environmental effects rather than traffic. These works are programmed in advance and include such activities as, for example, culvert cleaning. Data integrity That feature of data that relates to its completeness and internal consistency. Database A computer-based collection of data that normally uses formalised rules for the way that the data are stored. Decision-support system A computer-based system comprising applications modules to process data and provide enhanced information on which informed decisions on road management can be based and, ultimately, implemented. Deterministic The class of decision making processes where outcome is predicted as a precise value on the basis of mathematical functions of observed or measured inputs. Development works Projects planned at discrete points in time that result in improved road capacity or changes in alignment. Emergency works Works undertaken to clear a road that has been blocked. Fourth generation (4GL) An advanced computer programming language, usually used for programming language interrogating databases. Global cost The ‘broadest brush’ category of cost-estimating technique which r elies on libraries of achieved costs of similar works; eg cost per kilometre o f bituminous resurfacing. Hardware The physical components of a computer system, including processor, keyboard, monitor and printer. HDM-III The ‘Highway Design and Maintenance Standards Model Version III’, which is a computer-based decision-support system, developed by the World Bank, and used for economic appraisal of road projects. 64 Information quality level (IQL)Criteria developed by the World Bank for grouping data in terms of their level of detail and other attributes to assist in specifying data collec tion that is cost-effective when used in conjunction with road management systems. Information system A computer-based system that collects, organises and stores data. Information technology (IT) All aspects related to the use of computers to assist with management or other activities. Institutional appraisal An investigation of an organisation that identifies its strengths and weaknesses, success in meeting defined aims, and the constraints under which it operates. Inventory A record of the physical attributes of the road network or other asset being managed. Local area network (LAN) A system of linking computers in fairly close proximity, such that each can have access to common peripherals, data and software. Logical design A written description used as a starting point in developing computer software. This includes a detailed description of the functions, processes and data structures of the processes for which computer software is to be written, but described in such a manner that is independent of the programming language to be used by the software or the hardware on which it will run. Maintenance management system A computer-based system for assisting with the management of maintenance (note that in UK English, this term will often be used synonymously with the term ‘pavement management system’ whereas, in US English, the term will normally refer to an ‘operation s management system’); to avoid confusion, the use of this term should be avoided. Management cycle A series of well-defined steps which take the management process through the decision making tasks. Typical steps would be i) define aims; ii) assess needs; iii) determine actions; iv) determine costs a nd priorities; v) implement activities; vi) monitor and audit. The proces s typically completes the cycle once in each periodic cycle of the particular management function. Management function A means of defining a management task based on its objective. Management functions are undertaken so that the requirements of the policy framework are met; examples are planning, programming, preparation and operations . Map-based graphics Computer output that shows features and attributes of the road network spatially against a map background. Meta data Parameters input to a computer system that define the fundamental processes of operation of the system. Middle-ware Computer software that is used to interface between applications software and an RDBMS, such that the way that the applications software can be written is independent of the RDBMS. Mission (statement) This outlines, in broad terms, the goal of the organisation responsible for the road network, and justifies its existence. Model A mathematical function or algorithm that is used to simulate real life effects. Module/modular An entity that is broken down into discrete parts that can be developed, tested and operated independently of each other. 65 Multi-year programmeA schedule of road works planned to take place in discrete years into th e future. Network A particular grouping of roads for management purposes; examples are the national road network; trunk road network; paved road network, etc. Network information system An information system that stores data about the road network and its inventory. Network referencing The process of breaking the road network down into successively smaller links, segments and sections, each of which can be defined uniquely for road management purposes. Operating system Software mounted on a computer that provides an interface between applications software and the computer hardware. The operating system enables a user to make use of the hardware facilities of the computer, for example by organising where information is stored in memory, by storing, retrieving and copying files, and by looking after the input and output. Operation(s) The on-going activities of an organisation, for which management decisions are made on a near-term basis. Examples include the scheduling of work to be carried out, monitoring in terms of labour, equipment and materials, the recording of work completed, and the use of this information for monitoring and control. Operational cost A fundamental cost-estimating technique that builds up the total cost of the work from its component activities described by the method statement and programme, in terms of labour equipment and materials. Pavement management system A computer-based road management system, typically used to assist with planning, programming or preparation; to avoid confusion, the use of this term should be avoided. Performance standard This specifies the quality of finished work for an activity, and builds up a consistent description of the activity based on a preferred method of working, and requirements for equipment, labour and materials. Periodic works Works planned on a regular basis to take place at intervals of several years. Planning This involves an analysis of the road system as a whole, typically requiring the preparation of long term, or strategic, estimates of expenditure for road development and conservation under various budgetary and economic scenarios; predictions may be made of expenditure under selected budget heads, and forecasts of road conditions, in terms of key indicators, under a variety of funding levels. Policy framework A set of statements, normally comprising a mission statement, objectives and standards, that define in detail the aims of an organisation and how it proposes to achieve these. Preparation The near-term planning stage where road schemes and projects are packaged for implementation. At this stage, designs are refined and prepared in more detail; bills of quantities and detailed costings are made; together with work instructions and contracts; detailed specifications and costings are likely to be drawn up. Preventive works Addition of a thin film of surfacing to improve surface integrity and waterproofing that does not increase the strength of the pavement. 66 Priority indexA parameter whose value gives an indication of the priority of the associated activity. Probability/probabilistic The class of decision making processes where outcome is predicted as a probability function of a range of possible inputs. Problem tree analysis A method of problem solving that works backwards from a problem statement, breaking this down into more detailed components, and then develops these to find a solution. Procedure A documented series of steps for carrying out a particular activity or task. Programming The preparation, under budget constraints, of multi-year works and expenditure programmes in which those sections of the network likely to require treatment, and new construction possibilities, are identified and selected; a tactical planning exercise. Reactive works Works responding to minor defects caused by a combination of traffic and environmental effects. Recurrent budget The government budget which is normally used to fund those works that are needed every year, including such items as staff salaries, running costs of a road administration, and maintenance works for the road network which are undertaken on a regular basis. Reduced time period analysis A method of analysis used in computer-based prioritisation of road works that uses an approximate approach to life cycle costing that is less demanding of computer processing requirements. Relational database management Computer software designed to construct, modify and maintain a (RDBMS) system database, where the database stores data in a structured way in a number of database files, and where the detailed relationship between specified data items is defined. Road class/hierarchy A grouping of road sections according to pre-defined rules, often based on issues of ownership, function, funding source, etc. Road management The process of maintaining and improving the existing road network to enable its continued use by traffic efficiently and safely, normally in a manner that is effective and environmentally sensitive; a process that i s attempting to optimise the overall performance of the road network over time. Road management system A computer-based system used to assist with road management. Routine works Minor works that need to be undertaken each year. Software A set of instructions that can be stored in a computer and used to carry out pre-defined tasks; often referred to as a ‘program’. Spatial data Data that include geographic co-ordinates among their attributes so that they can be displayed using map-based graphics. Special works Works the frequency of which cannot be estimated with certainty in advance. Specification A detailed description of the attributes of the output from an activity, or of the steps by which that activity is carried out. Stakeholder Those with a vested interest in the performance of the road administration, including the road users, industry, agriculture and commerce, who are its ‘customers’, plus the road administration it self and the road engineering industry. 67 Standard (maintenance)A requirement, sometimes legally enforceable, that a road administration is obliged to meet as part of its road management activity. Strategic Pertaining to actions, often wide ranging, designed to achieve defined objectives in the long term. Strip diagram A report, often in the form of a computer output, that shows road featur es and attributes relative to the longitudinal, but not cross-sectional, po sition along the road. System A structured group of discrete entities which interact for a particular purpose; examples are:  A ‘computer system’, which is a collection of software and hardware designed to carry out a particular function  A ‘management system’ which is a set of procedures designed to assist the management process (which may also include a computer system) Tactical Pertaining to actions designed to achieve defined objectives in the short to medium term. Training levels A formalised approach to classifying skills and needs of individuals that assists in identifying training needs. Unit rate A cost-estimating technique based on the traditional bill of quantity approach to pricing engineering work, typically relating to aggregate quantities of work to be carried out, measured in accordance with an appropriate method of measurement. Un-interruptible power A device for storing electricity, that can be placed between computer supply (UPS) hardware and a mains power supply, that enables continued operation of the hardware for a reasonable period in the event of a failure of the mains power supply; the device normally has the further ability to ‘smooth out’ power surges and peaks in the main s power supply that could otherwise damage operation of the hardware or corrupt the software. UNIX (UNiplexed Information A proprietary computer operating system designed for efficient and Computing Service - UNICS) operation with large software systems and where many users are accessing the software or data at the same time; often used in connection with mini-computer or ‘work station’ hardware, but also available on micro-computers. Works All construction and maintenance activities. 68 Appendix B: Institutional appraisal check list (Developed from: Brooks, D M and others, 1989. Priorities in improving road maintenance overseas: a check- list for project assessment. Proc Institution of Civil Engineers, Part 1 . 86 (Dec), 1129-1141.)1 External (socio-political, contextual or environmental) factors 1.1 Legal and regulatory 1.1.1 Is there a Roads Act which defines clearly the role and responsibility of the road administration? 1.1.2 Which organisations are responsible for different classes of road? 1.1.3 Are the legal powers adequate and, generally, are they understood by the road administration? 1.1.4 What is the influence of government or civil service procedures on operations of the road administration? 1.1.5 Is the road administration subject to external monitoring and audit? 1.2 Socio-cultural 1.2.1 Are there historical, social or cultural factors which affect the road administration’s operations? 1.2.2 Is t here a recognisable management culture in the country? 1.2.3 Are decisions in government independent of the influence of nepotism, favouritism, or corruption? 1.3 Political 1.3.1 What priority is given to road management compared with other sectors, and with other activities in the road sub-sector? 1.3.2 To what extent are road administration staff political appointees? 1.3.3 To what extent are decisions made influenced by political factors? 1.4 Economics and resources 1.4.1 To what extent is the economy governed by market forces, and to what extent is it planned or controlled centrally? 1.4.2 What impact does the general economy have on the ability to manage the road effectively? 1.4.3 Is a budget awarded, is it adequate, and can it be relied upon? 1.4.4 Are operations independent of foreign exchange constraints? 69 1.5Overall employment policies 1.5.1 Are there sufficient personnel available at all levels? 1.5.2 Are they adequately educated? 1.6 Private sector 1.6.1 What is the government policy towards private sector, and how is this implemented in practice? What is the availability of domestic project financing? What is the availability of international/donor project financing? 1.6.2 What locally-based road consultants exist and where are they located: Domestic? International? 1.6.3 What locally-based roadworks contractors exist and where are they located: State-owned domestic companies? Joint venture state/private? Private domestic? International? 1.6.4 W hat is the workload of: Consultants? Contractors? 1.6.5 Competence: How well qualified and experienced are the domestic staff of: Consultants? Contractors? What equipment holding do contractors have? What is the quality of work produced? 1.6.6 Are bidding procedures: appropriate? transparent and free from corruption? How do contract documents compare with international norms, such as FIDIC? Is payment for works timely? Does the client have the ability to supervise, measure, test, etc? Is there access to arbitration? 1.7 Related institutions 1.7.1 Is the performance of the road administration dependent on the output of other organisations over which it has no control? 1.7.2 To what extent is the road administration subject to external competition? 1.7.3 What external incentives to performance exist? 70 2 Internal institutional (organisational, managerial and human resource) factors 2.1Policy framework 2.1.1 Does the administration have a mission statement, objectives and standards, and are these appropriate? 2.1.2 Is the policy fr amework appropriate and achievable? 2.1.3 Is policy based on economics, or other factors? 2.1.4 Are road plans produced for: Construction? Maintenance? and at what frequency? 2.2 Organisational and administrative structure 2.2.1 Is there an administrative structure that is appropriate for and capable of managing roads? 2.2.2 Are responsibilities defined, and are staff aware of these? 2.2.3 Is there an unambiguous chain of command? 2.3 Procedures 2.3.1 Do documented procedures exist for: Planning? Programming, including budgeting and setting priorities? Project preparation? Management of on-going operations? 2.3.2 Are the procedures understood and applied? 2.4 Resource management 2.4.1 Is there a regular and formal budgeting process? 2.4.2 Is the budget based on assessed or measured need? 2.4.3 Is the budget related to actual costs and the ability to disburse? 2.4.4 Are procurement procedures appropriate, efficient and independent of corruption? 2.4.5 Does full finan cial control reside within the maintenance organisation? 2.4.6 Are accounts independently audited? 2.5 Human resources 2.5.1 Is there a manpower inventory, and career development records for all staff? 2.5.2 Is there a manpower plan which is used as the basis of staff recruitment, deployment, utilisation and advancement? 2.5.3 Are compensation, benefits and incentives adequate to motivate staff? 2.5.4 Is systematic staff appraisal carried out against performance standards as an input to the career development process? 2.5.5 Do adequate sanctions exist to deal with indiscipline, and are these implemented? 2.5.6 Are staff adequately trained, and is there an internal training scheme? 71 3 Technical (engineering and physical) factors 3.1Data 3.1.1 Is the network referenced, and is this up-to-date? 3.1.2 Does an inventory exist for the road network and its structures, and is this up-to date? 3.1.3 Is th ere adequate traffic and axle load data, and is this up-to-date? 3.1.4 Does sufficient up-to-date condition data exist to enable needs to be assessed? 3.1.5 Is road accident data collected and analysed in a systematic manner? 3.1.6 Is unit cost data available and up-to-date? 3.1.7 To what extent are computer-based information and management systems available and used? 3.2 Materials and supplies 3.2.1 Are appropriate materials and supplies of the right quality available as required? 3.2.2 Are the properties of materials used fully understood? 3.2.3 Are there adequate testing facilities, and is the quality control of products and materials adequate? 3.2.4 Are appropriate materials always used? 3.2.5 Does an adequate system exist for ordering, storing and stockpiling materials and supplies? 3.3 Plant and equipment 3.3.1 Is there a fleet of plant and equipment of the size and composition required? 3.3.2 Is the availability adequate? 3.3.3 Is the u tilisation adequate? 3.3.4 Are the workshops and stores adequate to support it? 3.3.5 Is there an organisation capable of managing the fleet cost-effectively? 3.3.6 Is adequate financial provision made for replacement and repair? 3.4 Operations 3.4.1 Do appropriate design methods exist, and are they used? 3.4.2 Are there specifications for work, and are these met in practice to achieve adequate quality control on site: For works carried out by direct labour/force account? For works carried out by contract? 3.4.3 Are contract procedures satisfactory and enforced? 72 3.5Monitoring and feed-back 3.5.1 Is work done measured and costed? 3.5.2 Are costs realistic in terms of overheads, equipment, materials and labour? 3.5.3 Is cost and monitoring information collected centrally and used for planning and budgeting purposes? 3.5.4 Is there a physical inspection and audit of work done? 3.5.5 Is productivity measured? 3.6 Access to research and information 3.6.1 Is there adequate access to current research work and good practice from other organisations or research centres? 3.6.2 Is relevant research currently carried out within the organisation? 3.6.3 Are new techniques and practices introduced as a result of research results? 73 Appendix C: Example applications of the information quality level concep t (Source: Paterson, W D, 1991. Choosing an appropriate information syste m for road management. In: PIARC. 19th World Congress of PIARC, Marrakesh, September 1991. Paris: P ermanent International Association of Road Congresses). Table C.1 Road inventory Data groupIQL-I IQL-II IQL-III IQL-IV Length (1) (1) (1) (1) Vertical alignment Centre line elevation Max gradientRise+fall(1) Gradient(2) @ 10-100m centres Av absolute gradient Av absolute gradient Length non-compliant Horizontal alignment For each segment: Maximum curvature Curvature(1) Curvature(2)  Transition points Av curvature  Curve parameters Length of tangent  Sight distance Length non-compliant Number non-compliant Min design speed Transverse profile Camber Camber – – Superelevation Superelevation – – Pavement width Pavement width Width(1) Width(2) Shoulder width(3) Shoulder width Shoulder width(1) Shoulder(2) Shoulder types(3) Shoulder type Shoulder type(2) – Lane widths(3) Lane width(2) Lane width – No of lanes No of lanes No of lanes No of lanes Lane types(3) – – – Median types(2) Median type Median(2) – Median width Median width – – Kerb type(2) Kerb type Kerb(2) – Kerb height (L,M,R) Kerb height – – Formation Type(1) Type(2) Type(2) Type(2) Height(L,R) Height(2) – – Width Width(2) Width – Side slope(L,R) Slope(2) – – (1) = Field measurement (2) = Pre-defined range options for estimation (3) = Every point in data set L,M,R = Left, middle, right Av = Average Max = Maximum 74 Table C.3 Characteristics of options for deflection measurement MeasurementDevice OperatingApplied CapitalOperating Collection speed method type principle load (kN) cost cost(1) (min per reading) Moving wheel loads Benkelman beam Manual + truck 80 H D 10 Travelling deflectometer Automated vehicle 80 B D 0.6 Deflectograph Automated vehicle100-130 C D 0.6 Steady state vibratory loads D ynaflect8Hz trailer-mounted 0.5 E E 1.3 Road rater 6-60Hz trailer-mounted 0.1-24 E E 2.7 Impulse load Falling weight deflectometer Impact trailer-mounted15-270(2) D E 1.3 B US$200 000-400 000 C US$100 000-200 000 D US$60 000-100 000 E US$30 000-60 000 H US$<2 000 (1) Annual cost for regular usage (2) Range varies with make Table C.2 Methods of measurement for pavement structural evaluation Data group IQL-I IQL-II IQL-III IQL-IV Summary of Detailed data for Summary data for Summary pavementCategory of (relative) measurement method individual layers individual layers strength index pavement strength Alternative methods 1) NDT + AL + CR 1) NDT + (FS or CR) 1) NDT 1) Visual survey of measurement 2) DS + LS + (LL or CR) 2) DS + (LS or LC) 2) FS + FC 2) Inferences from 3) FS + LC 3) CR condition data AL = Material loading behaviour algorithms CR = Construction records DS = Destructive sampling FC = Field material classification FS = Field shear test (eg cone penetrometer) LC = Laboratory material classification LL = Laboratory material loading behaviour LS = Laboratory material stiffness test NDT = Non-destructive test (deflection) Whichever approach is adopted, it is recommended that some visual assess ment of pavement condition is always made to tie into t he pavement strength assessment. A range of methods can be used to collect information on surface distress (for example, cracking and deformation) and riding quality, and the principles of the IQL approach should be adopted for these surveys as well. 75 Table C.4 Minimum spatial sampling rates and methods for pavement struct ural evaluation Data groupIQL-I IQL-II IQL-III IQL-IV Minimum sampling 3-20m intervals 20-100m (min 5 points per 0.3-1.0km (min 5 2-5% network rate/interval RP: every joint or crack section) in each wheel path points per section)length (stratified RP: 20-40m in outer JRP: at slab centre random sample) wheel path and jointseg 0.5km per 10km Data group for method IQL-I or IQL-II Minor roads: IQL-II or IQL-III IQL-III or IQL-IV of measurement IQL-II or IQL-III (see Table C.2) Major roads: IQL-I or IQL-II Subjective description of Defl based on NDT Defl based on FWD, DG Defl based on Defl based on viable assessment methods plus MS or BB; SN based on DCP; FWD or DG FWD or BB; SN plus MS where necessary based on CR or DCP; Resid based on visual survey BB = Benkelman beam CR = Construction records of layer thickness and strength DCP = Dynamic cone penetrometer Defl = Deflection measurements at surface DG = Mobile deflectograph FWD = Falling weight deflectometer JRP = Jointed rigid pavements MS = Field or laboratory materials tests, as required Resid = Residual life RP = Rigid pavements SN = Structural number computation Table C.5 Traffic volume and axle loading for different information qual ity levels Data group IQL-I IQL-II IQL-III IQL-IV Volume Total volume AADT, seasonal AADT and seasonal AADT AADT and seasonal factor AADT range ADT, hourly and short-term flows Directional By direction and lane By direction, average heavy None None characteristics vehicles per lane Composition By vehicle class By vehicle class By 2-3 categories Proportion of heavy (eg heavy, bus, light)vehicles Loading Axle loading Axle load spectrum Average ESA per vehicle Link/region average ESA Regional average ESA class, maximum axle load per vehicle class per heavy vehicle Gross vehicle mass Spectrum by Average and maximum None None vehicle class by class Tyre pressure Average and maximum None None None by vehicle class 76