The FRAME Architecture is intended to be used to help the planning and deployment of integrated ITS for a region over a period of time (see diagram below). An ITS Architecture is created for that region to show what is required. Then, in each financial period, a set of applications or services can be chosen and the System Requirements Specification and the Test Specification parts of a Call for Tender can be written using the descriptions obtained from the relevant parts of the ITS Architecture.
A second way of considering the planning process is shown in the waterfall lifecycle below, which shows the tasks to be performed and who performs them. This shows that a typical ITS deployment can be a two stage process. In the first stage a local authority or road operator produces a Call for Tender. In the second stage the company that wins the contract develops and deploys the equipment. An ITS Architecture is created during the first stage and is used to provide many of the details of the Call for Tender.
A third way of considering the planning process is shown in the diagram below.
Once an ITS Architecture has been created various issues can be studied and products created as follows:
- System Boundary – Shows what is provided by the system and what is not, and the relationship between the System and the parts of its environment with which it interacts (see also The FRAME Model)
- Component Specifications and Communications Requirements – for Calls for Tender
- Deployment programme – the plan for he deployment of equipment and communication. This includes what to do with existing systems and equipment
- Organisational Viewpoint – who owns and/or manages and/or operates each part of the integrated system (see also How can you plan Organisational Issues)
- Cost/Benefits Study – the costs and the expected benefits of the ITS deployment (see also How can you undertake a Cost/Benefit Analysis?)
- Risk Analysis – deployment hazards, their risks and possible mitigations (see also How can you undertake a Risk Analysis?)
A fourth way of considering the planning process is shown in the diagram below.
Once an ITS Architecture has been created from the FRAME Architecture the requirements of the communications links (physical data flows) can be compared with existing communications standards and technologies. If these already exist then they should be used, but if not then it may be necessary to initiate their development.
If necessary the ITS Architecture, and its communications requirements, can be analysed as described in the “third way” above, and changes made if found to be necessary.
The ITS Architecture, and its communications requirements, form the basis on which the Procurement Process takes place, which leads to the ITS implementation.
“Many Languages, One Voice” from Thinking Highways Vol 6 No 1, Mar/Apr 2011