RESEARCH PROJECT FINAL REPORT Scheme Business Case Tool An international research project funded by The Applied Research Programme in High Volume Transport (HVT), Transport-Technology Research Innovation for International Development (T-TRIID) An initiative from The Department for International Development (DFID). Prepared for: IMC Worldwide Prepared by: Peter Davidson Consultancy Ltd Research undertaken in conjunction with Athari Capital (Pty) Ltd, Johannesburg, South Africa and Gauteng Provincial Government, Department of Roads and Transport, Johannesburg, South Africa Peter Davidson Tel: +44 (0) 1442 879075 Email: mail@peter-davidson.com 2 Contents Executive Summary.............................................................................................................................4 Abbreviations......................................................................................................................................5 Chapter 1: Introduction ....................................................................................................................6 1.1 How does transport modelling improve scheme design ..............................................................6 Chapter 2: The Challenges with Current Methods...........................................................................8 2.1 The challenges...............................................................................................................................8 2.2 Opportunities..............................................................................................................................10 2.3 Risks ............................................................................................................................................10 Chapter 3: Objective and Aims.......................................................................................................11 3.1 Objective .....................................................................................................................................11 3.2 Aims.............................................................................................................................................11 Chapter 4: The Scheme Business Case Tool and its Prototype.......................................................11 4.1 The solution: the scheme business case tool (SBCT) ..................................................................11 4.2 The Prototype Scheme Business Case Tool - Phase 1 of 4 of the SBCT ......................................14 4.3 Assumptions made......................................................................................................................15 4.4 Technologies and equipment used.............................................................................................15 4.5 Limitations...................................................................................................................................15 4.6 Illustrative comparisons of the cost of modelling: Pretoria and West Midlands .......................16 Chapter 5: Feedback From End Users.............................................................................................17 5.1 Stakeholder workshop and training............................................................................................17 5.2 Limited Market testing................................................................................................................17 Chapter 6: Next Steps.....................................................................................................................19 6.1 SBCT phase development ...........................................................................................................19 6.2 Seeking funds for the phase 2 SBCT development .....................................................................19 Chapter 7: Conclusions...................................................................................................................20 Appendix A Design and implementation of the scheme business case tool (SBCT).............................22 A.1 Overview.....................................................................................................................................22 A.2 System architecture....................................................................................................................22 A.3 The model run architecture........................................................................................................24 A.4 Types of user...............................................................................................................................25 A.5 Sequence of steps needed to build and run a transport model.................................................26 A.6 System components ...................................................................................................................28 A.7 Skills transfer, training and institution building..........................................................................29 A.8 Business considerations..............................................................................................................29 A.9 Implementation phases..............................................................................................................30 Appendix B Technical Details of the PSBCT ..........................................................................................32 Appendix C Analysis of Google Cloud Platform ....................................................................................35 Appendix D Results of the training course and market testing ............................................................36 D.1 Stakeholder Workshop and Training..........................................................................................36 D.2 Market testing results ................................................................................................................36 D.3 Challenges Facing the Roads and Transport Authority Gauteng Province.................................38 Appendix E Illustrative PSBCT Website Screens ...................................................................................41 Figures Figure 1.1 The transport scheme design process showing its business case components....................6 Figure 1.2 The role of transport modelling within a scheme’s business case development..................7 Figure 4.1 Overall architecture of the Scheme Business Case Tool (SBCT) ..........................................13 3 Figure 4.2 Sample of PSBCT website screen thumbnails......................................................................16 Figure A.1 Overall architecture of the Scheme Business Case Tool (SBCT) ..........................................23 Figure A.2 The model run architecture and how it fit in with the overall architecture .......................24 Figure A.3 The Role of transport modelling within a scheme’s business case development...............26 Figure A.4 Transport model development tasks...................................................................................27 Tables Table 4-1 Illustrative costs and timescale for preparing a business case for a major scheme in Pretoria conventionally and with SBCT.................................................................................................17 Table B-1 Top Level menu of the prototype SBCT and the screens they lead to .................................34 Version Control Version Date Author Checked Issued 1.0 26/03/2019 A Thomas P Davidson 26/03/2019 2.0 05/04/2019 A Thomas P Davidson 05/04/2019 3.0 30/04/2019 P Davidson P Davidson 07/05/2019 4.0 17/05/2019 P Davidson P Davidson 20/05/2019 5.0 12/06/2019 A Thomas P Davidson 14/06/2019 6.0 24/06/2019 A Thomas P Davidson 24/06/2019 Issue Status Author(s) Reviewed By IMC Approved By Issue Date V1-V5 Draft A Thomas and P Davidson Bruce Thompson 26/03/2019 V6 Final A Thomas and P Davidson Graham Fiveash Bruce Thompson 25/06/2019 4 Executive Summary Transport scheme development from scheme identification to the start of construction takes many years. A key part of that is forecasting the traffic and revenue for the Business Case (BC) using a transport model. The objective addressed by this project is to develop a Scheme Business Case Tool (SBCT) to considerably reduce the timsecale and costs of the transport modelling to weeks rather than years. This will also make it simpler, less risky and more likely that the right schemes will be identified and built, with consequent improvements to the local economy, social stability and people’s wellbeing. The SBCT would be a website and cloud based system for developing the transport model and using it to produce the traffic, ridership, revenue and other outputs required for a scheme business case. Government officers, consultants, funding agencies and others would be able to go onto SBCT’s website, input their scheme and forecast the traffic, ridership and revenue for their scheme’s BC, much quicker and much cheaper than currently. It will provide the internet-based platform for holding transport data as a resource for the future so that the transport modeller can integrate it into his model more effectively and enabling it to be shared between transport models. It will tap directly in to use mobile phone network data (MND) and other sources of Big Data. It will provide on-line tutorials, help, guidance and facilities to help redress the modelling skills shortage in developing countries and support their local centres-of-excellence. SBCT would be free for simple models such as for Outline Business Cases (OBCs) in developing countries, and for more complex models such as required for a Full Business Case (FBC), there may be a charge especially for data, but the charge would be much cheaper than conventional methods. It would be available for developed countries too with an element of cross subsidy from them. The implementation would seek partners with Mobile Network Data (MND) suppliers who would be paid for their data and these costs would be passed on to the data user. The implementation would seek partners from governments who could provide a financial contribution in return for consultancy support in building their transport models and doing BCs. To test SBCT’s proof-of-concept and to find out if there is a market for it, this project designed the architecture of SBCT, developed a prototype (PSBCT) and market tested it with a limited number of potential end users from Gauteng Provincial Department of Roads and Transport (GPDRT), in the Gauteng Province, South Africa. The results showed that SBCT was technically possible, that it could fulfil an important market, that it will save time and money, simplify the modelling, reduce risk, give guidance and provide the robust scientific underpinning for Governments to make better informed decisions on the feasibility of transport projects. As a minimum SBCT would be taken up by a few Governments which in itself would be worthwhile but it is also possible that with the right design SBCT could well take-off as a resounding success across the developing and developed world. The next steps required to develop the SBCT and make it available to public agencies, consultants, government departments, funding agencies and academics in low income countries, have been set out in this document in three phases. It would be available for the market at the end of phase 2 for the preparation of highway scheme business cases at a cost of about £350,000 including about £150,000 to cover the cost of MND. Two further phases would cover public transport and other more complex schemes for a combined cost of about £350,000 including about £150,000 for MND. After that it is anticipated that the SBCT would be self-financing including the MND costs which would be borne by the users. 5 Abbreviations API Application program interface BC The scheme business case comprising an OBC and an FBC FBC The scheme full business case including detailed design GDP Gross Domestic Product GPDRT The Department of Roads and Transport, Gauteng Provincial Government, Pretoria, South Africa GPS Global positioning system, whose data is from the GPS navigation system in cars, trucks etc MND Mobile phone network data obtained from the mobile phone companies showing peoples travel OBC The scheme outline business case comprising outline design to decide whether to progress with a scheme. Sometimes called the pre-feasibility stage or the feasibility stage PDC Peter Davidson Consultancy Ltd PSBCT Prototype scheme business case tool. The prototype of the SBCT which was developed on this project and which is the first of four phases developing the SBCT SBCT Scheme business case tool 6 Chapter 1: Introduction When a government seeks to improve its transport system, it needs to identify transport problems and the solutions needed to fix them. These solutions comprise a set of possible schemes such as new roads, railways, busways etc. In order to build a scheme and open it to the public, it has to go through a process of scheme design before it is ready to be actually built. Scheme design is costly and time consuming. For many schemes the design process is so long and costly that they don’t get built because schemes have many hurdles to cross during their passage through the design process, many of which have nothing to do with the scheme’s merit. For example a change of government may seek to differentiate itself by abandoning the transport schemes promoted by its predecessor irrespective of their merit. The long scheme design process is an important deterrent to building new transport schemes - the longer the design process the more likely that the scheme is killed-off. This project seeks to considerably reduce the scheme design process, reducing its costs, time and risk, thereby improving the scheme’s chances of being built, incentivising governments to build more transport infrastructure and freeing up funds for governments to build more. 1.1 How does transport modelling improve scheme design For the transport scheme design process, having indentified the scheme (figure 1.1), the initial questions that need to be answered are: is it worth the money? Will it be beneficial to society, the economy etc? There may be various options which need to be determined such as alternative alignments, locations for junctions, stations, bus stops, decisions about what tolls or public transport fares to charge, in some cases questions about will it be financially viable? These questions are addressed by the Outline Business Case (OBC) or pre-feasibility stage. The scheme may not be worthwhile or it may be of lesser priority and this can be discovered at the OBC stage. Governments have a limited funding so the OBC helps policy makers to prioritise. Figure 1.1 The transport scheme design process showing its business case components 7 Following Scheme Identification, the scheme is designed in detail for the Full Business Case (FBC) or detailed design stage. The Business Case (BC), comprising OBC and FBC is the most time consuming, most costly and most risky part of the scheme design process. Analysing transport problems, identifying transport solutions and forecasting traffic to design transport schemes for the BC, is a complex problem which requires a computer model of the transport system to solve it (see figure 1.2). The traffic on the scheme is forecast by putting the scheme into the the transport model. It can also forecast public transport passenger ridership, the revenue generated by fares or tolls, time savings, the benefit to society and so on. Alternative scheme variants (eg alignments, junctions, stations, routes, bus stops, fares, tolls etc) can be put into the transport model so as to optimise the scheme design. The transport modelling is used throughout the scheme design process. The transport modelling is perhaps the most critial part of the BC process for bringing schemes to be successfully built. It is generally on the critical path of the scheme design process and can take a minimum duration of one year and can possibly take several years depending upon the complexity of the scheme and the requirements of the Government, client and financiers. It is one of the most time consuming, expensive and risky part of BC development. Figure 1.2 The role of transport modelling within a scheme’s business case development Transport modelling therefore improves scheme design by representing design elements such as alignments, locations for junctions, stations, bus stops, pricing for tolls or public transport, etc. Alternative scheme variants can be tested in the transport model to find the optimal scheme design. 8 Chapter 2: The Challenges with Current Methods 2.1 The challenges Reducing transport modelling time, costs, complexity and risk The key challenge is to reduce the transport modelling time down to a matter of weeks and months rather than years. It is also to reduce transport modelling cost, complexity and risk and enable more of the work to be done by local staff in developing countries. To achieve this, it would be necessary to automate some of the key modelling processes. However, every BC is different, so the challenge is to automate with sufficient generality to cater for all BCs. The transport modelling comprises a set of steps which are essentially a combination of manual and computer processes undertaken in sequence which complicates the challenge of automating and speeding up the process. If a scheme is not viable, the challenge is to discover this as soon as possible with minimum effort at the OBC stage. Providing scientific rigour Transport modelling requires sufficient scientific rigour so the challenge is how to maintain this scientific rigour during the automation. The transport modelling for the BC needs to attract international funding agencies so the challenge is to maintain the high standard required. Avoiding duplication between schemes Governments may be considering a number of schemes at any one time, each of which requires transport modelling. There can be considerable overlap between the transport models of the different schemes involving considerable duplication of effort. The challenge is how to avoid this duplication. Overcoming institutional barriers The challenge is also to help overcome the existing and significant institutional barriers as articulated by the Department of Roads and Transport, Gauteng Provincial Government, Johannesburg South Africa (GPDRT) as follows: • The lack of integration within sector departments and other government agencies; • Modelling data is usually saved at one particular location and other users who require access to it, normally have to consult and become registered in order to retrieve and then use it; • The inability to integrate models effectively under one custodian and then to maintain them; • Long planning horizons, technological changes and rapid urbanisation; • In some cases, the lack of a Transport Authority to integrate the various types of transportation; • Lack of consistency in the use of compatible software in transport modelling when planning in the provinces and then developing proposals nationally; • Lack of information sharing amongst various departments and teams - For the Gauteng Province, this problem is so severe that even a national centre established by National Government to house various high-level skills and knowledge, refuses to share previous transport models that were created for the province; • Poor connectivity and linking of modelling processes from initial inception to final completion. 9 Providing a robust evidence-base for decision making The transport modelling process requires a robust evidence base and the challenge is to identify and assemble robust, reliable data in developing countries at reasonable cost. Transport models usually require considerable data collection, new surveys of the travel demand, current transport infrastructure etc. Such data collection can cost many hundreds of thousands or even millions of dollars. The challenge is to facilitate this and help make data collection, definitions, spatial detail etc consistent throughout the region so that it can be shared both by other users and other scheme developments. Facilitating data sharing Once it has been used in the transport model, data is effectively discarded and is not generally shared from one scheme development to the next, leading to duplication of survey and modelling effort when other scheme developments may be able to use this data. The challenge is to provide a resource which can be used to share data between scheme developers so as to reduce data collection costs, project timescale and lead to better models and better forecasts. This could also provide a platform whereby the scarce, expensive-to-collect resource of transport data can be kept permanently, accessible to all, with all the tools and metadata needed to use it effectively so that the next scheme developer can integrate it into their model more effectively. Leveraging Big Data There are various types of new data sources, collectively called ‘big data’ which are not currently used in developing countries. This data includes for example mobile phone network data (MND), global positioning system (GPS) data (for example from in-vehicle navigation, lorry tachometers, taxis) and other types of big data which record people’s movement, activities and behaviour. The challenge is how to make best use of the advantages of using this data while maintaining scientific rigour and keeping costs down. MND is owned by private sector companies who do not know how it can be used and try to exact a price which is too high – much higher than their costs and much higher than the alternatives. This challenge: • Is part institutional to make the big data providers aware of these uses of their data and of the appropriate costs they can charge. • Is part technical because specialist tools are needed to bring big data into the scope for use in the model. • If MND is collected in the right way, big data can be shared across multiple models. Transferring skills, software and capability Some of the other challenges with current methods are epitomised by those at the Department of Roads and Transport, Gauteng Provincial Government, Johannesburg South Africa (GPDRT) who identified the following: 1. Lack of access to quality transport modelling software; ensuring the use of similar, compatible software across all spheres of transport modelling and planning in the province and nationally, as well as allowing for ease of integration of various models; 2. Lack of knowledge and understanding of the fundamentals of transport modelling, the preparation of business cases, etc. There is a severe shortage of skilled transport modellers in developing countries, so the challenge is to help train transport modellers in developing countries and give them the skills to be able to prepare their own transport models and use them for the preparation of BCs. 10 3. Lack of access to reliable, external data for the preparation of transport models; The GPDRT indicated that the only information they have on the previous models is in hard copy format; lack of data collection; lack of trend analysis data; lack of updated data (household travel surveys, stated preference surveys, freight movement data, municipal data on transport, costings); lack of information on infrastructure assets; 2.2 Opportunities Transport modelling software tools and processes have evolved with the changing needs of the projects and changing computer technology. Modelling techniques have developed with more accurate methods for forecasting traffic and revenue and the use of good quality MND to quantify travel demand. Recent computer technologies call for an evolutionary step change in to take account of: • the ability to access transport models from different locations via the internet; • the internet and its online datasets such as OpenStreetMap and Google Maps (further details in Appendix C); • the availability of good quality MND which could reduce data collection costs. MND data could be extracted automatically, in minutes rather than the months required to collect survey data and be directly useable for the transport model. • recent academic research results: for example, research into the values-of-time across Africa which developed a set of relationships between a country’s GDP and travellers’ value-oftime1 . There is an opportunity to bridge the gap between research and practice. • parallel processing to speed up the frequently very long model run times. • The ability to hold transport networks and their variants centrally to make them available across multiple schemes. • The next logical evolutionary step is to transfer transport modelling to the web where it can be accessed via the internet. The problem of transport data not being shared between scheme developments and of being discarded once used, could be addressed by providing an easily-accessible platform for holding transport data. A scheme developer can then integrate this transport data into his model more effectively, enabling it to be shared between transport scheme developers by holding it as a resource for the future. The transfer the skills could be addressed by having on-line tutorials, on-line help while doing the transport modelling and on-line courses in conjunction with universities in the developed countries. 2.3 Risks There are risks associated with transport modelling and the challenge is to reduce them including: • The surveys not producing reliable data on which to build the transport model. • Poor survey and model data leading to wrong results. • A transport model comprises a set of mathematical equations which have to be developed from relationships estimated from the transport data. There is a risk of not being able to estimate the model equations from the survey data especially if the data is of poor quality, which will lead to poor modelling. • Poor modelling could lead to the wrong schemes being promoted at the expense of better ones, infrastructure being built which does not achieve its forecasts, and schemes getting built and subsequently not used. 1 For the 2017 Choice Modelling Conference in Cape Town 11 • Scarce resources get wasted building undeserving schemes when they could be better spent on more worthy schemes. This should be discovered at the OBC so the BC, particularly the OBC, is high risk and anything to reduce this risk would be beneficial. Chapter 3: Objective and Aims 3.1 Objective The objective of the project is the design of a prototype scheme business case tool that confirms proof-of-concept and tests the market potential for supporting policymakers in their decisions of whether or not to proceed with the detailed design and appraisal of a transport scheme. Developing the tool beyond a prototype would require extensive research and development – more than this project can deliver – would involve doing things which have not been done before, would carry its own risk of failure, so it is best performed in several phases. The objective of this initial project is to perform the first of four phases that have been identified. The four phases are described in Chapter 6. 3.2 Aims Within the project objective are a number of aims as follows: • to reduce modelling complexity which, with the appropriate training and guidance, would help increase the modelling work that can be undertaken by local staff thereby promoting local employment opportunities resulting in a contribution to local GDP etc. • to develop a training programme that would facilitate the required skills transfer and to get interest from both local companies and local Government organisations who would be willing to provide suitably qualified resources to deliver the training programme. The training programme should cover the transport modelling needed to develop an OBC, FBC and for scheme identification. • to build-in good practice into the training programme, by providing the appropriate methodology suited to the particular BC with direction to guide transport model developers through the various modelling steps. • to provide an audit trail to ensure transparency for those who need to scrutinise the scientific underpinning of the BC in order to attract international funding agencies. Chapter 4: The Scheme Business Case Tool and its Prototype 4.1 The solution: the scheme business case tool (SBCT) This project seeks to facilitate the scheme design process by building a specialised tool to do the transport modelling for the scheme identification, OBC and FBC. This tool should considerably reduce the time taken, the costs, the risks and complexity of developing a scheme and redress some of the institutional barriers identified above. Phase one of the four phases identified to fully develop this scheme design tool involves the preparation of a prototype tool to determine whether there is a potential market for it and whether it is technically possible. It comprises the following: 12 • the specification, architecture and outline design of the tool. • development of a set of prototypes to discover problems and help solve them – particularly those aspects which have not been performed before and have a higher degree of risk. • provide a visualisation to illustrate the way modellers interact with it. • the visualisation to market test with independent transport planners on real use-cases so as to refine the design on the basis of their feedback. • the market testing accompanied by training in transport modelling for BC so as to make the market testing more realistic. The scheme design tool that will facilitate transport modelling for the BC will be achieved with a Scheme Business Case Tool (SBCT) which will give practitioners all the necessary functionality (shown earlier in red in figure 1.2), on a website using the features which can be programmed into the internet application. The SBCT web based tool will automate many of the processes needed to perform the transport modelling and will meet all of the challenges, aims and objective set out above. Government officers, consultants, funding agencies and others would be able to go onto the SBCT website, input their scheme and forecast the traffic, ridership and revenue for their scheme’s BC, more economically and efficiently than is currently possible. It should reduce the level of risk of failure in developing a BC and the risk of it overrunning on timescale and/or budget. SBCT will provide the internet-based platform for holding transport data as a resource for the future so that the transport modeller can integrate it into his model more effectively and enable it to be shared between transport models. It will tap directly in to use MND and other sources of Big Data. It will provide on-line tutorials, help, guidance and facilities to support local centres-of-excellence. There are two main types of data used by transport modellers: the network (information about transport infrastructure and services) and the demand (information about where people travel from and to). Some network data can be obtained from maps, and some from elsewhere. This can be put on the SBCT database with metadata for future users. Demand data usually comes from surveys which give a partial picture, and then modelling extends this to give the full picture. Survey form templates can be provided via the SBCT as well as data from previous surveys. It is possible to standardise some data fields, with metadata to explain the data structure and contents. To enable reuse of data between projects in the most efficient way, international data standards should be published and followed. Some work towards this standardisation has been undertaken by practitioners in the USA. SBCT would be made available free of charge to certain parties for development purposes. The optimum pricing structure will be investigated when the final tool is up and running. It is possible that SBCT would be free for simple models such as for OBC’s in developing countries, although there may be a charge for its data, which will be much more economical than conventional methods for other more complex models. It would also be available for developed countries with an element of cross subsidy from them. The implementation would seek partners with MND suppliers who would (if necessary) be paid for their data and these costs would be passed on to the data user. The implementation would seek partners from governments who could provide a financial contribution in return for consultancy support in building their transport models and creating BCs. Users of SBCT will interact with its website (see figure 4.1) and the rest of the functionality will be built behind it as background functions. It will work, by passing requests for data or to run the model back to the web implementation behind it. The System Database will keep track of run requests, users’ login and various web settings such as lists of network scenarios, demand scenarios, setups the user has set up for the model outputs, model run specification, and projects. The Model Archive, archives model and system data which is not needed anymore but which the user does not want to 13 delete yet. Model runs may take some time to execute so would best be performed through a background run queue which would process each run request in turn through the model analytics. The rest of the website’s functionality can be provided within this architecture where for example, screen input functionality that does not need to be queued, can be processed normally providing an immediate response to the user. The application architecture comprises the components described as follows: • Website: this provides all the front-end interaction with the user. Users input their scheme, build their model, run their forecasts and prepare their outputs through this website. It comprises the screens which require user input, provide user output or perform actions for the user via functions. All the model data is created, displayed, edited and deleted through these website screens. • Functions: these perform background actions for the user. One of the main functions will be to run the transport model which queues the run requests, takes the model inputs, runs the model and produces the user outputs. • Web database: keeps track of run requests, users’ login and various web settings such as the configuration requirements the user has set up for the model outputs, model run specification, network scenarios, demand scenarios, and projects. • Model interface: this is an interface to the transport model written in C# (pronounced as C Sharp) with various Application Program Interfaces (API) which are needed for the model analytics. • Model analytics: this performs the necessary transport modelling actions required by the user in order to build the transport model, maintain it, develop forecasting scenarios, run the model to forecast the traffic, ridership, revenue and benefits and produce the various outputs that are needed. The model analytics is where all the modelling is done. • Model database: this holds all the data needed for the model including the networks, demand scenarios, model specifications, run options, display options, inputs and outputs. It also holds details of all historic model runs (other than those that have been archived). Figure 4.1 Overall architecture of the Scheme Business Case Tool (SBCT) More detail of the SBCT including its design is given in Appendix A. 14 4.2 The Prototype Scheme Business Case Tool - Phase 1 of 4 of the SBCT This project developed the Prototype Scheme Business Case Tool (PSBCT) which is phase one of the SBCT in order to provide its proof-of-concept. The PSBCT comprised the specification, architecture and design of the SBCT together with prototypes of some of the functions (in figure 4.1) to solve key problems and the website (see figure 4.1) to illustrate the facility provided to modellers. It did not contain the functionality behind the website, apart from a few prototype functions and a queuing facility, because this was beyond the scope of the current project. The PSBCT was used to assess whether SBCT is worth pursuing further. If it is, then subsequent phases will be used to gradually develop it. A training programme to facilitate skills transfer was also developed and delivered to a local firm Athari Capital and a local government Gauteng Provincial Department of Roads and Transport (GPDRT). GPDRT are the transport authority for the province which includes the cities of Johannesburg and Pretoria as well as a fairly large rural area. The training programme covered the transport modelling needed to develop an OBC, FBC and for scheme identification. This was followed by limited market testing of the PSBCT with trainees on their real use-cases, the results of which were used to refine the PSBCT design on the basis of their feedback and was instrumental in assessing the overall market potential for the SBCT. PSBCT was adapted as a result of the market testing in order to develop it to more closely match its potential market. The PSBCT website was built to illustrate the various facilities that are provided to modellers. It comprised screen mock-ups connected together, with explanations and real-world examples to tell potential users the story of how to develop a scheme business case using the PSBCT. This project therefore developed the following: • the design of the SBCT. Further details are provided in Appendix A. • a prototype of the website interface. Further details are provided in Appendix B. • a prototype of the web implementation. This is provided in Appendix B. • a training programme and market testing with GPDRT. This is provided in Appendix D. • the limited market testing and updating the website interface and web implementation. This is provided in Appendices B and D. • developing the case for building the SBCT. This is provided in Appendix A. The prototype of the website interface is where the user performs the modelling work. It consisted of a set of website screens, accessed via a web menu system which requested the user input and data needed. It contained all the main website screens needed to undertake all the SBCT functionality. However, the PSBCT did not do anything with this user input and data (the full SBCT will when it is built). The website interface will invoke functions of the web implementation to perform the actual work. The prototype of the web implementation comprised a set of software prototypes which explored its functionality and how it would perform the actions required by the website interface. CitiLogik’s web interface for extracting data from MND was also prototyped. Prototype functions were written to put requested actions and functions into a queue, to then take requested actions and functions from the queue, to run a transport model, to pass run status messages back to the website interface and to display model run results. In order to run a model, the work for the prototype had also to get a test version of PDC’s modelling software running in background mode. 15 4.3 Assumptions made The success of the SBCT largely depends on users wanting to use it, which relates back to what benefits it provides and how effectively it provides them. The work PDC undertake on scheme BCs plus the limited market testing of the PSBCT, supports our assumption that there is an overwhelming appetite for SBCT. It also requires users to want to use a ‘cloud based’ web platform that will involve making regular monthly payments for its use, rather than the more historic and conventional single one-off payment for software that is then installed on the user’s individual computer server, which would be a change of culture for many of them. For the fully functional SBCT to be developed, there are some technical assumptions to be made about being able to solve the remaining problems. These include: • A test version of PDC’s software has been converted to run a model in background mode (which one of the prototypes explored) but there is other functionality that needs to be converted to run in background mode. The prototype has shown that this is possible. • Reading and writing to databases from the different web components to aid communication between them is definitely achievable. • Implementing standard internet security some of which is provided through the Microsoft Azure ‘Cloud’ environment which was used for PSBCT. This is a normal part of any IT implementation procedure involving a modern web application. • Resolving the efficiency issues of parallel processing when executing background functions with potentially long run times. The PC version of PDC’s software utilises parallel processing facilities but many of the functions have not yet been converted to run in background mode. • Adapting the model analytics functions to support multiple users. • The Microsoft Azure and other ‘Cloud’ platforms are ‘paid-by-use’ as are MND requirements. The assumption is that ultimately these costs will need to be recovered from SBCT users. It is assumed that agreements can be made with the mobile phone companies to purchase the use of their MND. Mobile phone companies in some countries have been contacted with some success2 which indicates that this may be possible but there is the possibility that some countries may not provide this service as they may not see the merits initially. The assumption is that they will be persuaded ‘once the ball is rolling’. Even in the case that MND is not available for a particular study area, the tool can still be used with data from traditional sources. 4.4 Technologies and equipment used The PSBCT used Microsoft Azure web services for the website application within a ‘Cloud’ platform. More technical details of the technologies and equipment used for the PSBCT are given in Appendix B and for SBCT in Appendix A. The SBCT should be built to conform to W3C standards. 4.5 Limitations The PSBCT website contains screen ‘mockups’ (some example thumbnails shown in Figure 4.2, with full size versions in Appendix E) to illustrate how the SBCT might work but these screens are currently not functional. These are provided to support the proof-of-concept, to find out whether it has market potential and assess whether it is feasible to create the full SBCT. 2 For example UK, USA, Europe, Kuwait, Lebanon, Bangladesh, Nigeria, Botswana, Lesotho and South Africa. We have not found any locations where no mobile network operator has agreed to provide data. 16 Figure 4.2 Sample of PSBCT website screen thumbnails We conclude that market potential does exist and it is technically feasible to move to the second phase of development. 4.6 Illustrative comparisons of the cost of modelling: Pretoria and West Midlands The city of Pretoria in Gauteng province, South Africa, was used as a case study to assess the potential savings in timescale, costs, risk and complexity in producing an OBC and FBC using both a conventional approach and an approach using the SBCT. Pretoria, an urban area with a population of 2.1 million people, was selected as the case study because it was identified in the training and market testing with Gauteng Provincial Government as a possibility for scheme development in the near future. These cost and time estimations are based on PDC’s experience in undertaking BC developments in Africa and elsewhere3 . Major transport schemes in urban areas are often more complex and expensive than inter-urban schemes because they generally require both highway and public transport models with public transport data collection as well as highway data collection, extensive congestion and more complex mode and destination choice modelling. For comparison, Pretoria has about the same population as the West Midlands (UK) where the original model was built in 2001 costing £1m for data collection plus £1m for model development and the traffic and revenue forecasts for a major scheme OBC could cost £150,000 and for a FBC could cost £0.5m (total £2.65m). At todays prices this would total about £3m. The surveys took a year and the model development another year, adding an OBC and a FBC to these requirements could add another year giving about a 3 year study period. The detailed engineering design, social, environmental, financial and other non-transport costs associated with preparing the BC’s have been excluded and could add a further 3 years or more. The BC preparation for major schemes in developing countries is generally to a lower standard with less data and less intensive modelling, so preparing a transport model for Pretoria, although it is the same size, would generally cost less than the West Midlands. The relative BC preparation costs for a major scheme in Pretoria (illustrated in Table 4-1Error! Reference source not found.) show a conventional BC preparation cost of $1.260m against the comparable preparation costs which could be achieved with SBCT (excluding engineering design and other non-transport appraisal costs) as $0.77m, a saving of about 40% ($0.49m) with a comparable elasped time saving of a year (ie 60%), 3 PDC bid for projects such as these on a competitive basis so have a reasonably accurate appreciation of their costs and timescales - those given here are such budget estimates. 17 down from 20 months to 8 months. These are considerable time and cost savings. They are just for one BC and there are many BC’s in preparation in the world at any one time. These time savings could be much higher than a year for some requirements and in some circumstances 2 or 3 years may be possible. Table 4-1 Illustrative costs and timescale for preparing a business case for a major scheme in Pretoria conventionally and with SBCT In addition more of the work could be done locally and with SBCT being internet based, this could be possible with joint working with UK counterparts. For example, one of the most resource intensive components of staff time is the coding of the transport networks in the model. The main mapping would be abstracted from open-source datasets but this needs to be augmented with local knowledge. This could be improved, if it could be performed locally with those who have an intimate knowledge of the transport system, highways, congestion etc actually doing the coding. Coding locally is less risky and the local counterpart staff will have a vested interest in getting it right. Chapter 5: Feedback From End Users 5.1 Stakeholder workshop and training About 20 staff members of the GPDRT attended the training led by the Chief Director for Planning, Freeman Masuku on 4 and 5 March 2019 at the office of Gauteng Provincial Government in Pretoria. Subsequently GPDRT requested another day of training on 6 March aimed at a smaller, more senior, audience which was headed by the Deputy Director General of the Department of Roads and Transport. PDC’s transport modelling consultant, undertook the training. The response from the participants was overwhelmingly positive, particularly for the modelling theory, case studies, simplification of complex modelling and examples of actual data collection. Freeman Masuku, Chief Director Policy and Planning summed up as follows: “The international experience opened our minds to issues that we were not really looking at and this will greatly assist us going forward in improving Transport Planning in the province and enhancing evidence - based decision making.” 5.2 Limited Market testing The PSBCT was demonstrated to potential transport planning users from GPDRT, for their feedback and thoughts about applying SBCT on their current and potential schemes. The participants varied from very senior chief directors to more junior transport planning and modelling individuals. After asking participants to consider their actual or potential schemes, they were asked to consider how they would use SBCT to deliver them. Costs $'000s Timescale months Without SBCT With SBCT Saving Without SBCT With SBCT Saving OBC 110 50 6 1 5 Surveys 30 0 Model development 80 50 FBC 1150 720 14 7 7 Surveys 600 340 8 3 Model development 550 380 6 4 Total 1260 770 490 20 8 12 18 The response was overwhelmingly positive and the GPDRT itself indicated a major need for it, with very enthusiastic requests to start using it immediately with many other stakeholders, government departments and institutions potentially using it. They anticipated SBCT could save them about 2-6 months. They thought that SBCT could be used for various projects that are currently being envisioned which includes public transport models, Bus Rapid Transit (BRT), feasibility studies, urban simulation, their Construction Unit, their Disaster Management & Policy Unit, their Environmental Unit (Green Energy) and they listed the following potential projects: • City of Johannesburg Transport Modelling Project (Strategic Model Update); • The review of the 25 years Integrated Transport Masterplan; • The Gauteng Province Transport model; • Modelling and testing of scenarios for Human Settlements Department and general spatial development projects; • Modelling the Gautrain high speed train network extensions; • Mixed land use projects within the Gauteng Strategic Road network; • Transport model for the Airport Masterplan as well as enabling the prioritisation on the construction of the road network in order to support the Airport Masterplan; • Implementations of new sections of freeways to alleviate congestion in existing intersections; • Conducting urban simulation growth combined with the road network; • Assessing the feasibility of, and modelling locations of truck stops and access roads in the province, as well as route determination; • Assessing the feasibility of Bus Rapid Transit (BRT), Rail, other modes of public transport on the provincial network; The participants also indicated that various stakeholders, from other government departments and institutions could benefit too (see Appendix D for a detailed list). They thought that SBCT could also help them develop future transport systems such as mobility as a service, help with data sharing and assist them to derive socio-economic impacts and future projections in terms of traffic and population growth. They considered that SBCT would help in: • Establishing business cases for funding; • Assisting program managers and project funders with sufficient information; • Establishing the priority of projects for implementation; • Providing an informed planning mechanism with quality assurance and quick turnaround; • Updating previous transport models and run them using new scenarios; • Refining the model zone system and updating market segment trips; • Estimating forecast demand for horizon years; • Retaining scheme appraisal data and the storing of historic data; • Provide transport modelling facilities accessible through the internet. Other feedback from the limited market testing was used to redesign the PSBCT’s prototype of the website interface. This redesign was implemented and it is the redesigned prototype of the website interface that has been delivered as part of this project. Appendix D gives more detail of the market testing results. 19 Chapter 6: Next Steps 6.1 SBCT phase development Implementing SBCT would best be undertaken in phases, so as to take it from the current proof-ofconcept phase 1 onwards to market with subsequent phases to cover highway schemes, public transport schemes and more complex schemes as summarised below and given in detail in Appendix A: 1. Phase 1 developed the PSBCT to determine whether it would be possible to deliver SBCT technically, whether there is a market for it, to identify and to solve key technical issues and then to design it. This phase has been completed by this research project. 2. Phase 2 would develop SBCT for highway schemes and make it publicly available. More detailed costs would need to be worked out but phase 2 is initially estimated to cost in the region of £250k to build ready for the market including operating costs, marketing, training and support. MND data costs is estimated at about £150k per country would need to be added. It may be possible to partner with a government or other organisation to share the first MND data costs. After the initial MND investment per country then these could be partly or wholly self financing. 3. Phase 3 would add the facility to model public transport schemes. More detailed costs would need to be obtained but phase 3 is initially estimated to cost in the region of £150k to build the application ready for the market including operating costs, marketing, training and support. For this phase, the expectation could be for MND costs to be partly self financing but it would be necessary to also have about £150k to contribute to the MND costs which should be borne by users. 4. Phase 4 would add the facility to do more complex modelling. More detailed costs would need to be obtained but phase 4 is initially estimated to cost in the region of £150k to build ready for the market including operating costs, marketing, training and support. For this phase, the expectation could be for MND costs to be largely self financing. 6.2 Seeking funds for the phase 2 SBCT development Funding for the phase 2 and subsequent SBCT development would be sought and any advice or suggestions as to funding possibilities would be appreciated. Research funds would be applied for, as and when the opportunity arises. Projects are undertaken for clients and some may be willing to pay for some elements of SBCT development. SBCT would be used for PDC’s own projects which would also help its ongoing development. PDC’s clients often want the resulting transport models, so SBCT would be their main way of providing this. Fees would be charged to clients for SBCT access instead of standalone software licences. PDC also have a small budget for software development which is being used at the moment to continue the further development of the PSBCT. Phase 2 and subsequent SBCT development would be rolled-out to market in conjunction with selected potential users such as GPDRT, preferably with a few other sympathetic Government partners as well using the template developed for the training on this project. This could include: • Training on the fundamentals of transport modelling, preparing BCs and SBCT • Support their preparation of the BC for one or more of their schemes 20 • Institution-development which would include 1) in their country to support governments, 2) the development of centres of excellence at universities 3) the provision of university courses and 4) academic research Chapter 7: Conclusions This project developed the architecture and design for a web based Scheme Business Case Tool (SBCT) which will speed up and simplify the process of forecasting the traffic, ridership and revenue for scheme business cases. It developed a prototype of this tool (PSBCT) to provide a visualisation of the final website and prototype particular implementation issues. It trained about 20 potential users from one Provincial Government (Gauteng Provincial Government South Africa). It undertook a limited market testing exercise with them whereby they considered their various schemes and they found that SBCT would be used extensively, saving them many months of time. The PSBCT visualisation (the prototype of the website interface) was adapted as a result of the market testing in order to develop it to more closely match its potential market. The analysis undertaken and the limited market testing that was carried out showed that SBCT could fulfil an important market that will save time and money, provide guidance and the robust scientific underpinning for Governments to make better informed decisions on the feasibility of transport projects. With the right design SBCT could well take-off as a resounding success across the developing and developed world. This project has learnt much more about the type of SBCT to build as well as who will use it and for what types of applications. The proof of concept phase has met the following challenges: 1. To reduce the time taken to prepare an OBC, FBC and scheme identification. as shown in the market testing and the application which showed that SBCT could reduce this by many months. 2. To reduce institutional barriers in order to encourage knowledge sharing, expertise, data and the models themselves. This project met these challenges by providing a common SBCT web platform accessible to everyone via the internet. The information and knowledge obtained on this project will also ensure that when the full SBCT is implemented, it will meet its various challenges as follows: 1. To reduce costs by using mobile phone network data (MND) and existing data sources, reducing inputs and simplifing the modelling workload. 2. To reduce duplication and overlap between schemes by setting common standards and building a common modelling platform accessible to all via the internet. 3. To facilitate data sharing with SBCT’s transport database on a common modelling platform. 4. To ensure good quality data. This was accomplished by obtaining good quality MND, SBCT providing guidance on new data collection and following international standard data processing. 5. To redress the shortage of modelling skills SBCT provided on-line training, tutorials, walkthroughs, user help and support and help to local centres of excellence. 6. To maintain scientific rigour which is provided by the use of international standard tools and techniques, together with the training, support and user guidance. This to a standard suitable to attract international funding agencies. 7. To reduce the complexity and modelling risk by providing good quality data, practical tools, training and guidance within SBCT. 21 By considering the business case (BC) preparation costs, for a possible major scheme in Pretoria, a saving of about $0.49m or about 40% was estimated by using SBCT (excluded engineering design and other non-transport appraisal costs); and a saving in time of approximatley one year (60%). Reducing the timescale of developing a scheme from idea to construction means that a viable project has a greater chance of succeeding and attracting finance, making it more likely that schemes will go ahead and be built. The next steps required to move towards developing the SBCT and making it available to public agencies, consultants, government departments, funding agencies and academics in low income countries, have been set out in this document in three phases. It would be available for the market at the end of the next phase (phase 2) for the preparation of highway scheme business cases at a cost of about £350,000 including about £150,000 to cover the cost of MND. Two further phases would cover public transport and other more complex schemes for a combined cost of about £350,000 including about £150,000 for MND. After that it is anticipated that the SBCT would be selffinancing including the MND costs which would be borne by the users. SBCT would be free for simple models such as for OBCs in developing countries, although there may be a charge for data, and be much cheaper than conventional methods for other more complex models. It would be available for developed countries too with an element of cross subsidy from them. The implementation would seek partners with MND suppliers who would be paid for their data and these costs would be passed on to the data user. The implementation would seek partners from governments who could provide a financial contribution in return for consultancy support in building their transport models and doing BCs. 22 Appendix A Design and implementation of the scheme business case tool (SBCT) A.1 Overview The SBCT will be an internet website supported by web implementation background processes for transport modellers to build a transport model and use it to prepare a BC. Transport modellers would log onto the website, define their study area and their scheme and the SBCT will get the mapping data, MND, GPS data etc. from the various online databases where it resides and guide them through building a transport model to their specifications. The SBCT will help them calibrate and validate their model interactively with the manual processes automated in software. The user can then input their scheme interactively on a map background and run the model to produce an initial set of traffic and revenue forecasts for the OBC. Background parallel processing services can be used to speed-up the sometimes very long model run times. For the FBC, the user may need to do collect more data or do more surveys for example willingnessto-pay surveys and do more work of a more conventional nature to refine the model but the SBCT will speed-up this process by automating the manual parts of the tasks. The SBCT will have the facility for uploading user’s data so that they can use it as part of their model. It would also over time build up a databank of data to support other users in future. The SBCT would thereby be a website which would gradually accumulate transport data as a world resource for the future. This could be tapped-into by researchers to enhance understanding of developing countries travel, by government so that they could see what other governments are doing to improve their transport system and by practitioners so that they can produce scheme business cases quickly at lower cost to the taxpayer. There is a web service (from a company called Citi Logik who supply Vodafone data) which can supply MND automatically from a web-generated query. The Citi Logik web service has been prototyped for this project. SBCT would be independent of the Citi Logik web service and could use theirs or anyone else’s data. The user could get any GPS, MND or other big data themselves, upload it into SBCT and use it instead of, or as well as, the Citi Logik data. Ideally the Citi Logik web service would be extended to include other countries. PDC is happy to co-operate with Citi Logik. The current state-of-the-art is to undertake surveys comprising face-to-face interviews of people’s individual trips. However, using big data the SBCT will reduce the survey time to the few minutes necessary to download the data from the internet. Some surveys (for example, willingness-to-pay surveys) may still need to be done with face-to-face interviews but in some cases, these can be undertaken in parallel with the other work. A.2 System architecture Model runs can be instantaneous for small models or they take some considerable time, for example the West Midlands model takes 24 hours to run. It is therefore important to deal effectively with multiple users and long model run times. This has governed the design of the system architecture (see figure A.1) which uses a queue for model run requests in case there are a lot of them. Run requests are then taken from the front of the (first in first out) queue and the specific model request is then run. When the current model run has been completed the next model run request is then run until the queue is empty. These actions are performed by functions which put model run requests into the queue and take them off and run the model request. 23 Figure A.1 Overall architecture of the Scheme Business Case Tool (SBCT) The model itself comprises the model interface which passes execution of the run to the model analytics. Both of these have access to the Model Database which hold the data comprising the transport model. The Web Database keeps track of run requests, users’ login and various web settings such as lists of network scenarios, demand scenarios, setups the user has set up for the model outputs, model run specification, and projects. The Model Archive, archives model and system data which is not needed anymore but which the user does not want to delete yet. The rest of the website’s functionality can be provided within this architecture where for example quick functionality not requiring to be queued, can avoid the queuing mechanism. The system architecture comprises the components described as follows: • Website: this contains the screens which require user input, provide user output or perform actions for the user via an Internet application that is run in a ‘Cloud’ environment. All the model data is created, displayed, edited and deleted through these screens. • Functions: these perform actions for the user. One of the main functions will be to run the transport model which queues the model run requests, takes the model inputs, runs the model and produces the user outputs • Web database: keeps track of run requests, users’ login and various web settings such as lists of setups the user has set up for the model outputs, model run specification, network scenarios, demand scenarios, and projects. • Model interface: this is an interface to the transport model written in C# (pronounced C Sharp) which requires the use of Microsoft .Net enabling the building of various Application Program Interfaces (API). • Model analytics: this performs the necessary actions required by the user that require nontrivial processing such as running the transport model. • Model database: this hold all the data needed for the model including the networks, demand, scenarios, model specifications, run options, display options, inputs and outputs. It also holds details of all historic model runs (unless they have been archived). 24 • Model database archive: this holds all the model and system details of models which are not needed but which the user does not want to delete yet. This integrated process will automate the many interconnected manual and computer-based tasks reducing the budget, timescale and costs of transport modelling. This is helped by using a set of ‘wizards’ to guide the user through the model development tasks together with a ‘tasks system’ which describes the tasks the user has to complete before proceeding to the next steps. This also addresses the problem of quality control and transparency by providing an internet-based platform for sharing and retaining data, model specifications and model results. Notably, having such processes in place could assist in early project realization, and project cost savings. It should be built to conform with W3C standards. More technical details about the SBCT website are given in Appendix B. Appendix C analyses the possibility of including data from Google Cloud. A.3 The model run architecture Running the model is perhaps the most complex of actions which the system needs to perform because as well as running the model, it needs to pass progress messages back to the user, so they can monitor the run as it progresses. The software prototypes addressed the best way of performing a model run and the final design is shown in figure A.2. The model run is instigated by the user clicking the model “Run” button on the run request screen. This triggers the initiation of a model run request, initially the system gets a run request universally unique identification (UUID) from the operating system. This run request UUID is used to uniquely identify the run request within the system and is passed to the run status screen. Figure A.2 The model run architecture and how it fit in with the overall architecture Meanwhile, the queue insert function is called giving the run UUID together with the meta data needed to specify the run (the run specification data). The queue insert function inserts the run 25 request, with the run specification data and run UUID, into the back of the run queue. The queue insert function then contacts the web database with the UUID and inserts a message into the system run request table for that UUID in its message data area, to say that the run request has been put into the run queue. If there is at least one run request in the run queue, then this triggers the run queue server function which takes the next run request from the front of the queue, looks at what it needs to performed from the run request specification data and then actions it. For a model run this will normally mean calling the appropriate model interface function. Meanwhile the run queue server function puts a message in the web database to the effect that it has taken the run request from the queue and has started running it. The model interface function calls the model analytics to do the actual model run and as it proceeds, it puts its progress messages into the web database, culminating in a ‘done’ message when the run is complete. Control then passes back through the model interface to clean up and through the queue server function to also clean up and put a final ‘done’ message in the web database. The final message will give some idea of whether the run has been successful or not. While all this is going on the run status website screen which is sitting in front of the user, polls the web database run request table with its run UUID to get whatever messages have been placed there with the final message indicating success or not. The user can then view the complete run log if they wish to see what exactly has happened. This is necessary in some cases because model runs can go wrong. For example, in very congested conditions the run may not converge to a unique solution so the user may wish to increase the number of iterations or set different convergence criteria. The user can then get the outputs they need. Outputs can be set up in advance so they come out automatically when run has been completed. The website functionality (i.e. everything within the cloud in figure A.2) is computer code, written in the computer languages C# and C++ for the Microsoft’s Azure ‘Cloud’ platform. The technologies used and their rationale is as follows: • Microsoft Azure - available worldwide, use-based operating cost model avoids large-scale capex investment, key-enabler for dynamic scaling; allowing the systems to scale up as required. • Kubernetes - emerging industry standard, decouples applications with the underlying system allowing them to be as transportable as possible, orchestrates application deployment to achieve multi-node resilience with low effort. • PHP - quick-start web page templating support allowing quick prototyping. • Azure Functions - maximizing compatibility with existing Windows-based software, easy to integrate with other Azure cloud services such as file stores and databases, familiar language for model software developers. • Scalability in particular SBCT is likely to generate a huge amount of data and potentially a need to elastically scale, based upon usage. A.4 Types of user The transport model contains the complete network of roads and public transport routes, with the pattern of origin to destination trips which use it, plus the behavioural mechanisms which cause travellers to chose how to make their journeys (see figure A.3). By putting the scheme into the the transport model, it is used to forecast the traffic on the scheme, the public transport passenger ridership, the revenue generated by fares or tolls, air quality, the benefit to society for economic appraisal and so on. Alternative scheme variants (eg alignments, junctions, stations, routes, bus stops, fares, tolls etc) can be put into the transport model so as to optimise the scheme design. A 26 transport model should therefore be used for a scheme’s OBC and a more refined version should be used for its FBC. A transport model can also be used for the Scheme Identification stage. Figure A.3 The Role of transport modelling within a scheme’s business case development SBCT would target five types of user: • Model User: for preparing the traffic, ridership, revenue or benefits for a new scheme, or new scheme variant, maybe with different forecast assumptions, and to develop a business case. These users would require an ability to develop a new network scenario from an existing network and/ or to adjust the forecast demand scenario, perhaps to include a different land use/ population assumptions. They would need to prepare a set of outputs for reports including traffic, ridership, revenue and benefit outputs. • Model Developer: who would develop the functionallity of the model. • Student: to support those at university studying for a first or second degree such as an MSc in Transport potentially in association with centres-of-excellence in each developing country s to foster their transport planning and engineering profession. • Academic: to support research on transport modelling. This would also support academic research in centres-of-excellence in each developing country that fosters transport planning and engineering profession (?). • Administrators: who need to administer the website. A.5 Sequence of steps needed to build and run a transport model The conventional transport model development comprises a set of steps (see figure A-4) which are essentially a combination of manual and computer processes undertaken in sequence. A transport model comprises software which models any transport scheme and transport data which adapts this to the particular transport scheme being modelled. The transport model replicates the pattern of travel demand that includes travellers’ decisions on trip destination, mode of transport, time of travel, route origin to destination, including any toll. The model also reflects changing transport 27 conditions that affect travel decisions, and sometimes the longer-term interaction between land use and transport. Figure A.4 Transport model development tasks PDC has the necessary software to build and run transport computer models which it uses for its BC’s. It needs to be converted from the personal computer to work on the internet web-cloud platform. In the SBCT, the user builds and runs a transport model taking the following steps: 1. Study area: Develop the modelled study area and zoning system by accessing existing online mapping and existing online datasets. The user can edit this manually to include local knowledge. 2. Base year network(s): Develop the model highway (and if necessary public transport) network(s) using online mapping, existing on-line datasets. The user can edit this manually to include local knowledge. 3. Base year demand: Develop the model’s pattern of travel demand which quantifies the number of trips from every zone to every other zone drawing on MND, user surveys and data which other SBCT users have uploaded. 4. Run the model: The model is run which takes the pattern of demand. For each origindestination set of trips, it finds their path through the network and adds these trips to the links on their path. This is repeated for all travel demand so as to provide the traffic for every link in the network. This is undertaken for the current (or base) year and the traffic flows checked against independent traffic counts to ensure the model represents current travel. 5. Code the future network scenario(s): The new scheme is coded into the network(s) as a network scenario. Other variants can be coded as other network scenarios. 6. Code the future demand scenario(s): The current pattern of demand is projected into the future, usually by reference to GDP, population, car ownership and other variables which 28 can be forecast by other agencies such as the World Bank. This can be suitably modified with local new developments in particular zone(s) if necessary. 7. Run the model forecasts: the model is run again but with the future network and demand scenarios to produce the model outputs of the traffic, ridership, revenue and benefits for economic appraisal. A.6 System components The prototype SBCT and the market testing has shown that the SBCT should have the following components (items 1 to 5 were addressed in the PSBCT’s prototype of the website interface and item 7 was piloted in the training given to GPDRT participants): 1. Transport Database to allow users to upload and hold transport data, to support data sharing with special facilities for origin-destination demand data, transport networks and MND. 2. Model Runs to run an already-built model. This should support the most commonly used functionality which is to adapt the existing model to produce a new demand scenario or network scenario. The new scheme would be coded into the network scenario by the model user who could also code into the model an alternative future population and land use for a new demand scenario. They could run the model, set up and produce alternative outputs. 3. Model Build to build the transport model. This would include building the demand matrices from MND and other sources; building transport networks; building the demand forecasting model component. Demand forecasting model components can be very complicated especailly for complex transport schemes so initially this should focus on supporting one basic modelling technology, the most common being the 4 stage transport model. 4. Wizards to to guide the user through the sequence of steps needed to develop a model from scratch, to set up model runs and set up model outputs. 5. Help System and ‘tool tips’ to provide online additional information for users. 6. Administrative System to maintain and administer the SBCT. This would include systems for login, charging, back-up and recovery, queue monitoring, file storage monitoring and security. 7. Training Facilities to support teaching transport modelling practice targeted at potential users who have a background in transport planning or engineering. This can include written descriptions, video lectures, tutorials and exercises. The SBCT will come with a set of in-built models for people to play with and the Botswana Government has been asked for use of their models as test data suitably anonymised. Two models were prepared for them: an urban model for Greater Gaborone and a National model of the whole or Botswana. 8. Guidance on the type of models to build for different circumstances with links to International standards such as the UK Department for Transport’s (DfT’s) Transport Analysis Guidance (TAG - previously known as WebTAG). This would help guide Government officers and other project sponsors. 9. A Networks Management System (NMS) to keep track of transport networks, their schemes, scheme variants, connections, and opening years. Schemes can be dependent on each other or can or compete with each other. It can be important to test scheme variants, combinations of schemes or investigate scheme phasing. This complexity can be compounded with different schemes for different forecast years and where different modellers are coding different scheme variants from different offices. In these circumstances the network coding for one scheme can become inconsistent with the coding for another scheme. 29 10. An Automatic Modelling Project Task Management System (PMS) to instigate modelling tasks to be performed, allocate these to specific project staff with descriptions of what is to be performed , monitor the task progress, update tasks when they have completed together with details of any issues found. This component would enable project sponsors to monitor project progress automatically and would provide an audit trail for model provenance. 11. Public Transport The current prototype focussed on highway schemes but there is a clear need to also include other modes such as Public Transport. This could be a subsequent phase to SBCT. 12. Interactive Model Workbench for building more complex models. 13. Emerging Modes The market testing also identified interest in including other modes of transport particularly the new Emerging Modes such as mobility as a service (eg electric shared cars), app based sevices such as Uber/ Lyft) as well as to anticipate such new modes as electric cars, connected and autonomous vehicles. A.7 Skills transfer, training and institution building The SBCT would support skills transfer to local staff and institution-building. The institution-building is best comprising a local university, a UK university, local government modelling team(s) and local consultant modelling team(s). As well as doing research into transport, the local university would preferably deliver a transport part of a BSc and/ or a transport MSc in conjunction with the UK university and PDC have links with the University of Southampton for this. The university graduates would get jobs in government and consultants. Transport modellers seem to get promoted fast so there is usually a constant need for new graduate transport planners and modellers. The academic research can use the models developed for Government and they would be in touch with other transport academics through international conferences. One of the best transport conferences in the world is the European Transport Conference and PDC play an active role in this conference as Peter Davidson is currently the chair of its transport modelling committee. A.8 Business considerations Being a web based system SBCT would incur ongoing operating costs which would have to be paid on a monthly basis. Ongoing staff costs would be incurred for administration, maintenance, security, marketing, support and training. Other costs would include the usual office overheads. These ongoing costs would need to be covered from revenue from SBCT. The intention would be to have part of SBCT free to users but as PDC would need to cover its costs and make a profit for re-investmant in the business these costs would need to be met from the revenue generated from SBCT users. However, for maximum take-up it would be best if as much as possible was free for as long as possible. There are several possibilities for how the free/ pay functionality is split. It could be that small problems are free while the more complex ones incur a cost. Most developing countries problems tend to be fairly small and simple while developed countries problems tend to be much larger and more complex so this has the advantage that developed countries would tend to subsidise the developing countries. It could be free for model developers and academics but model users pay for extra run time and maybe extra storage costs. Model runs would be put into a queue and run in turn, so the longer the queue the longer the turnaround time so it may be that users get the queued service free but pay to by-pass the queue. As a long-term strategy it would be beneficial to make as much as possible free of charge for as long as possible to ensure more extensive take-up of the SBCT. 30 MND is likely to incur considerable costs on the user, finding the funds to assist users in paying these costs therefore needs special attention. MND requires an up-front cost to buy the data which could come from the scheme BC or provided by others or it could be bourne by SBCT (either from revenue, or retained profits or by borrowing) or some combination of these. There would need to be a system where these costs could be recouped from subsequent users of this data. Model developers who are working on a scheme BC would need to get their data from MND as well as doing some surveys themselves. Their MND is likely to be specifically for that scheme so it would be better if the MND specification could cover a wider area or the whole country so that it could be used for other schemes. This is likely to need additional funds which could come from SBCT or others in some way. In some cases a model could be built to cover the whole of an administrative area. For example, Gauteng Province would most likely develop a multi-mode model of the whole of their province, perhaps with specialist components for the major urban areas of Pretoria and Johhannesburg, so to address all the BC’s they wish to prepare, they would need to rank the schemes in order of the highest benefit-to-cost ratio (BCR) and build the most beneficial first. In this case the MND request could cover the whole of Gauteng Province but it may be possible to collect funds from other authorities in order to cover the whole of South Africa with MND. SBCT can act as a focus for this and as a facilitator. Once there is an established revenue stream from reselling MND, it may be possible to borrow money on the lending market as an investment. A.9 Implementation phases Phase 1 would develop a PSBCT to determine whether it would be possible to deliver SBCT technically, whether there is a market for it, to identify and to solve key technical issues and to design it. This has been completed by this research project. Phase 2 would build the Fully Functional SBCT for all five user types and cover system components 1 to 10 in section A.6 above. This would allow users to prepare a BC for highway schemes. The SBCT can be used anywhere throughout the world but the MND is area-specific so initally MND matrix building would need to concentrate on selected countries. Various countries have been approached through the company Citi Logik and the mobile phone network companies in South Africa and Nigeria could be sympathetic to selling their data to SBCT but this could be decided in conjunction with DFID and IMC. When completed, the phase 1 SBCT would go live so this phase would need to have recruited sufficient staff to support the administration requirements of SBCT which would include site maintenance, user support and user training functions necessary for a fully operational website. More detailed costs would need to be worked out but phase 1 is initially estimated to cost in the region of £200k to build and implement ready for the market. MND data costs are estimated at about £150k per country which would need to be added. It may be possible to partner with a government or other organisation to share the first MND data costs. After the initial MND investment per country then these could be partly or wholly self financing. Marketing, training and support costs also need to be added. Phase 3 would add public transport, build more detail onto the phase 1 functionality, (system component 11 in section A.6 above) and add MND for additional countries. This would facilitate business cases for other modes of transport such as rail, bus, bus rapid transit, tram, high speed rail etc as well as multi-modal solutions such as preparing a transport plan for a country, region, city, town etc. More detailed costs would need to be worked out but phase 2 is initially estimated to cost in the region of £100k to build ready for the market. For this phase, the expectation could be for 31 MND costs to be partly self financing with some £150k of seed money to contribute to the MND costs bourne by users, plus marketing, training and support costs. Phase 4 would build on phase 2 and cover system components 12 and 13 in section A.6 above, including additional behavioural mechanisms and new modelling techniques such as agent-based modelling. These techniques are used for specialist models or where other features are important such as parking, peak spreading, severe congestion, complex toll tariffs or emerging modes of transport. More detailed costs would need to be worked out but phase 3 is initially estimated to cost in the region of £100k to build ready for the market. For this phase, the expectation could be for MND costs to be largely self financing. Marketing, training and support costs also need to be added. After this SBCT should be self-financing. 32 Appendix B Technical Details of the PSBCT The overall architecture of SBCT is described in Appendix A. The SBCT prototype (PSBCT) consists of the website view plus a software prototype which address some of the SBCT components as shown in figure B.1. The website view consists of a series of web screens connected by a top-level web menu that allow the user to input their data, user requests and project specifications. The top-level web menu with the screens they open and a brief description of each screen’s functionality is given in table B.1. The website itself can be found by putting the following URL into a web browser (we have not tested this for all web browsers. It should be built to conform with W3C standards). The URLs for the first and second prototype websites respectively are as follows: http://sbct.peter-davidson.ltd/ http://preview.sbct.peter-davidson.ltd/ Two versions of the website have been produced the first (Version 1) was the first design and was used for the market testing and internal testing. (Version 1 opens with the ‘Generate Study Area’ screen.) Version 1 was redesigned in the light of the internal and market testing to give version 2. (Version 2 opens with a description of the objectives of the website, information about the project and its project sponsors and contributors.) This report describes version 2. The website is a set of screens and narrative which navigates a user through the modelling process. The screens are nonfunctional and are only provided to illustrate the website’s functionality so it can be visualised by potential users and for market testing purposes. When beginning the build for a new model, PSBCT takes the user through a wizard (see table B.1) where they specify the study area (fully modelled area, areas of interest, etc.), generate the zoning system, and code the connectors that define the zone system element of a transport model. This wizard then passes the user to a second wizard which takes them through building the highway and possibly even public transport network from existing mapping and online data. The user can then upload their own network data for inclusion in the network. The user is then guided into a third wizard for building matrices which form the demand part of the model. The user is subsequently provided with three different methods for building matrices; through roadside interview or other origin-destination data, MND data, and/or existing matrices. The user is then provided with screens to generate model engine assemblies used for setting up model runs. This web functionality would be available for developing both base year and future year scenarios. The software prototype addresses one user action – that of running the model - to investigate background queues, background functions, system database, model interface and model analytics (i.e. not model database or model database archive) so as to identify the best way forward for SBCT’s design. Running the model is perhaps the most complex of actions which the web application system needs to perform because as well as running the model, it needs to pass progress messages back to the user, so they can monitor the run as it progresses. The software prototypes addressed the best way of performing a model run and the final design is shown in figure B.1. The model run is instigated by the user clicking the model “Run” button on the run request screen. The rest of the implementation is described in in Appendix A section A.3 - The model run architecture. 33 34 Table B-1 Top Level menu of the prototype SBCT and the screens they lead to 35 Appendix C Analysis of Google Cloud Platform We have looked into the option of incorporating data from the Google Cloud platform (https://cloud.google.com/maps-platform/) into the Scheme Business Case Tool. Google Cloud platform is available as a paid subscription service. Amongst the data available, maps and routes could be of interest for the SBCT. The maps services provide a street view imagery and allows the user to produce customized maps. The routes service allows the user to extract travel time and distances between any two network points in the system. The Google Cloud platform allows the user to extract $300 worth of information on a free trial basis for a 12-month period. The free trial period ends upon either the $300 usage or 12-month period, whichever commences first. The Google Cloud service is a pay-as-you-go service with monthly subscriptions providing an additional $200 worth of data. The table below presents an approximate idea of how much relevant information $200 would fetch for potential use. Description Example usage Maps – Static street view uploads 25,000 - explore a bus stop with 360° Street View imagery Routes – biking/jogging routes 40,000 - routes with directions Routes - Distance Matrix 25 locations – travel time and distances with distance matrix Routes – route planner 100 points - smooth visualization with roads Routes Travel time with congestion along roads The Google cloud platform: • Deals with the current road system and cannot deal with proposed new infrastructure. • Does not hold traffic volumes and can’t predict them. • Its maps may be of use but there are other sources of maps such as OpenStreetMap which is a free crowd-sourced mapping dataset. • Its traffic speeds may be of use but there are other sources for this such as Waze data. • It calculates routes based on shortest paths, but the transport model’s algorithms do this – and they are done in the way that they are needed for the model – there is no need to pay Google to do them. The Google cloud platform is not a competitor to SBCT. It is complementary and could provide data. It is planned to keep the Google Platform under review. 36 Appendix D Results of the training course and market testing D.1 Stakeholder Workshop and Training Athari Capital organised with the Department of Roads and Transport, Gauteng Provincial Government (GPDRT) Chief Director their participation in this project. Up to 20 staff members attended the training led by the Chief Director for Planning, Freeman Masuku on 4 and 5 March 2019 at the office of Gauteng Provincial Government in Pretoria. Subsequently another day of training was added on 6 March aimed at a smaller, more senior, audience which was headed by the Deputy Director General of the Department of Roads and Transport. PDC’s transport modelling consultant, undertook the training. The training material was aimed at professionals at all skill levels including potential end-users of the SBCT, so that they can become familiar with modelling concepts, techniques and best international practice. The training material included the following: • Purpose of the study, issues and tools involving business case for new schemes; • Introduction to transport modelling: types of models and their use; • Model data and research methods; • Issues with data collection and quality; • Introduction to four stage models; • Choice models, discrete choice modelling, theory, stated preference, willingness to pay, tools with examples; • Emerging new modelling techniques; • Limitation and constraints of four stage modelling; • Agent-based, activity-based, and lifestyle modelling; • Real time traffic modelling; • Autonomous vehicles. The response from the participants was overwhelmingly positive, giving the course content a score of 4.1 and the trainer a score of 4.7 (out of 5) and overwhelming indicated that they would recommend the course to other users. They particularly liked the modelling theory, case studies, simplification of complex modelling and examples of actual data collection. Freeman Masuku, Chief Director Policy and Planning, a participant, stated: “The international experience opened our minds to issues that we were not really looking at and this will greatly assist us going forward in improving Transport Planning in the province and enhancing evidence - based decision making.” D.2 Market testing results The Scheme Business Case Tool was demonstrated to this limited set of potential end users for their feedback and thoughts about applying SBCT on their existing and potential projects. The participants included a wide range of individuals with varying levels of seniority, experience and skills. This consisted of a few very senior directors and department managers (e.g. chief directors, etc) to a number of more junior staff, transport planners and transport modelling individuals. A four-part set of questionnaires was given to attendees which was organised as follows: 37 • Part A Background: 5 Five questions that were aimed at finding out how much the attendees were involved in transport modelling-either as hands on practitioners or as staff members who were just aware of traffic models as part of their job. They were then asked to describe the challenges that the organisation faced in developing transport models and how they saw these challenges being overcome. • Part B Transport Modelling Website: this was aimed at finding out how much transport modelling was being used for project execution within their department, ways of improving the project execution and if transport modelling was to be web based what features would the attendees want to see in this approach. • Part C Feedback from the Modelling Website: this had 9 questions aimed at finding out if the web- based tool presentation met its objectives, what elements could be improved, what other stakeholders could benefit from such applications, etc. • Part D Feedback from Training: this solicited feedback from the attendees on how they rated the training, the trainer, aspects of the programme they enjoyed most and whether they would recommend the training to their colleagues/counterparts. The response received from the participants on the SBCT tool was overwhelmingly positive, with the participants and the GPDRT indicating a major need for the tool, with requests to start using it immediately. The participants were very enthusiastic, asking probing, pertinent, relevant questions with the participation at a very high level. Respondents anticipated approximately, 2-6 months in time savings if this tool was made available. The respondents opined that many stakeholders ranging from other government departments to institutions could benefit from this website. Given the website’s capability, respondents were of the opinion that its usage could extend to various projects that are currently being envisioned i.e. public transport models, Bus Rapid Transit (BRT), feasibility studies, urban simulation, their Construction Unit, their Disaster Management & Policy Unit, their Environmental Unit (Green Energy): a. City of Johannesburg Transport Modelling Project (Strategic Model Update); b. The review of the 25 years Integrated Transport Masterplan; c. The Gauteng Province Transport model; d. Modelling and testing of scenarios for Human Settlements Department and general spatial development projects; e. Modelling the Gautrain network extensions; f. Mixed land use projects within the Gauteng Strategic Road network; g. Transport model for the Airport Masterplan as well as enabling the prioritisation on the construction of the road network in order to support the Airport Masterplan; h. Implementations of new sections of freeways to alleviate congestion in existing intersections; i. Conducting urban simulation growth combined with the road network; j. Assessing the feasibility of, and modelling locations of truck stops and access roads in the province, as well as route determination; k. Assessing the feasibility of Bus Rapid Transit (BRT), Rail, other modes of public transport on the provincial network; The participants also indicated that various stakeholders including government departments and public sector institutions could benefit from the tool, these specifically include: 1. The Gauteng Provincial Govenments’ Construction, Disaster Management, Policy and Environmental (Green Energy) Units; 2. Universities; 3. City of Johannesburg; 38 4. Event planners to model traffic flow due to events around the given study area; 5. South African National Roads Agency (SANRAL); 6. Johannesburg Roads Agency (JRA); 7. Department of Rural Development and Land Reform; 8. Department of Human Settlements/Housing; 9. Department of Education; 10. Gauteng Provincial Department of Roads and Transport; 11. National Department of Transport; 12. Council for Industrial and Scientific Research (CSIR); 13. Passenger Rail Agency of South Africa (PRASA); 14. Airports Company South Africa (ACSA); 15. Department of Environmental Affairs; 16. Department of Economic Development; 17. Departments dealing with spatial development. To the question ‘Do you think this website will assist the development of future transport models/schemes’, the following responses were recorded: • Provides a clear understanding of new modelling concepts such as mobility as a service (MaaS); • Enables the sharing of transport modelling data ; and • Assists in deriving socio-economic impacts and future projections in terms of traffic and population growth. Responding to the question ‘How this website would have benefited existing projects, if it was currently available’, the respondents provided the following feedback: • Establishes business cases for funding; • Assists program managers and project funders with sufficient information; • Prioritises projects for implementation; • Informs the planning mechanism with quality assurance and quicker turnaround times; • Updates previous transport models and runs them based on new scenarios; • Refinines the model zone system and updates market segment trips; • Estimates forecast demand for horizon years; and • Retains scheme appraisal data and stores historic data. We found out from attendees that currently modelling data is normally saved on a server at one particular location. This then requires other users to consult and then request registration in order to retrieve this information from the given server . The SBCT would be able to alleviate this problem. The website updates (additions/deletions) recommended by respondents were mostly related to having an editable option, which would be covered once the full functionality of the system has been developed. D.3 Challenges Facing the Roads and Transport Authority Gauteng Province From the onset, through various preparatory meetings held by Athari Capital with the GPDRT before the start of this project (while trying to obtain the buy in into the research), as well as feedback obtained during the training and market testing, the following challenges facing the GPDRT were identified: 39 4. The extensive amount of time it takes to build transport models, generally this can be anything from a few months to years; 5. The substantial budget required to build transport models – In the Gauteng province, like many other provinces in South Africa and other emerging economies where there are limited resources and substantial needs, budgets for transport modelling are almost nonexistent; 6. Lack of access to quality transport modelling software; 7. A severe shortage of skilled transport modellers in the provincial departments and nationally; 8. Lack of knowledge and understanding of the fundamentals of transport modelling, the preparation of business cases, etc. 9. Lack of information sharing amongst various departments and teams - For the Gauteng Province, this problem is so severe that even a national centre established by National government to house various high-level skills and knowledge refuses to share previous transport models that have been created for the province; 10. Lack of access to reliable, external data for the preparation of transport models; 11. Lack of readily accessible, reliable, electronic data, including historical information and data, as well as from previous models. The GPDRT indicated that the only information they have on the previous models is in hard copy format; The participants also indicated the more specific challenges in developing transport models in their organisations as follows: 12. Data collection; 13. Trend analysis; 14. Poor linking of processes from start of a project to its completion; 15. Lack of updated data i.e. household travel surveys, stated preference surveys, freight movement data, municipal data on transport, costings; 16. Lack of information on infrastructure assets; 17. Lack of integration within sector departments and other government agencies; 18. Lack of consistency in the use of similar compatible software in transport modelling and planning in the provinces and nationally; 19. The inability to integrate models effectively under one custodian and to maintain them; 20. Long planning horizons, technological changes and rapid urbanisation; 21. The lack of a Transport Authority for the Gauteng province; The SBCT offers the following ways to overcome some the challenges identified above: 1. The use of Big Data (especially in emerging markets where cell phones are a basic necessity/way of life), making MND an even more robust source of data; 2. Skills transfer to develop transport modelling, data gathering as well as data processing capabilities through training and the SBCT guide, which is very key; 3. Institution-building in the country to establish a centre of excellence; 4. Use of the built-in-guide and processes in SBCT provides for improved model building as the fundamental principles of model building are automatically included in the website functionality; 5. The electronic functionality of the SBCT being critical in enabling the maintenance of models, and allowing data to be saved and shared electronically; 6. The SBCT will ensure the use of similar, compatible software across all spheres of transport modelling and planning in the provinces and nationally, as well as allowing for ease of integration of the various models; 40 7. The challenges of long planning horizons, technological changes and rapid urbanisation will be addressed through the ability to electronically store and easily manipulate data through the SBCT; 8. Cost saving, time saving, and other efficiencies inherent in the concept of the SBCT. 41 Appendix E Illustrative PSBCT Website Screens 42 Tools – generate highway network (wizard) – display and edit network 43 44 My data – demand matrix – build from origin-destination data Model development – network editor 45 Model runs - setup Model outputs - open - view