This page contains a Flash digital edition of a book.
ITS ARCHITECTURE FRAME


Figure 2: Component with interfaces (UML 2)


Figure 1: ITS Deployment programme


Organisational issues ITS implementations frequently involve both public and private organisations, including local authorities, public transport operators, equipment manufacturers and service providers. Before a service can be deployed successfully, their relative roles and responsibilities (financial and organi- sational) must be clearly established.9 Organisational issues comes from the system boundary


and the division the system into subsystems and modules (components). Each component is deployed and managed by a specific organisation that is responsible for developing and/or maintaining a defined group of functionalities. These human entities are responsible for the correct functioning of each part of the system, and the consequences of not meeting a defined service-level agreements could be easily defined. Another business objective is “to achieve the main goal of


deployment involves the hitting of a lot of subtargets – mean- ing not only the technology deployments but agreeing on who does what and working with the public authorities that will have to carry on the work after the project finishes, when there is no further funding.”10


Organisational issues help us to create good business models before the deployment starts.


Component specifications Most contemporary Intelligent Transportation Systems exist in highly dynamic environments. Their requirements change frequently and they must be built or modified on challenging development schedules. These systems are mainly decentralized and built from


modules called components. Every component has a com- ponent specification. Each component’s specification defines the basic characteristics of its interfaces (inputs and outputs) and operations, i.e. what it does. The development of plug- gable components is a key motivation for a valuable design approach. That is, it should be possible to understand pre- cisely what a component does based on the specification for the operations at its interfaces. It should be possible to replace one component by another that uses the same set of interfaces but operates in a different way i.e. traffic signal controllers’ software or hardware. It should thus be possible


60


to reuse a component reliably with several different systems in different contexts. See figure 2.


Communications Requirements Communications requirements define the characteristics needed by the physical data flows within the system and between the system and the terminators. The physical view- point creates the framework for the actual design of the sys- tem such as the location of the functions, the location of the data, etc. The choice communications mechanisms for the physical data flows are made through complex decision- making process, which is constrained by the sometimes con- trary demands of bandwidth and costs. Communications requirements are also highlight the need to use appropriate standards. The FRAME Architecture (physical viewpoint) shows us where the information comes from and goes to and through its definition of component locations helps to deter- mine what the communications requirements should be.


Cost Benefit analysis Cost Benefit analysis (CBA) is a technique for evaluating a project or investment by comparing the economic benefits with the economic costs of the activity. Benefit-cost analysis has several objectives. First, CBA can be used to evaluate the economic merit of a project. Second the results from a series of benefit-cost analyses can be used to compare competing projects. CBA can be used to assess business decisions, to examine the worth of public investments, or to assess the wisdom of using natural resources or altering environmental conditions.11


Cost benefit analysis should be an important


tool for ITS decision makers. It is closely connected to the component specifications from which the estimated cost of each component may be established using the specification produced from the physical viewpoint created for the system from the FRAME Architecture. Knowing the budget we can choose which components we


can afford with the precise definition of the interfaces needed for further development. Figure 3 shows that in this case we can exclude from hypothetical Terms of Reference compo- nent C and implement it when budget allows to do that. What


thinkinghighways.com Vol 8 No 3 Europe/Rest of the World


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60  |  Page 61  |  Page 62  |  Page 63  |  Page 64  |  Page 65  |  Page 66  |  Page 67  |  Page 68  |  Page 69  |  Page 70  |  Page 71  |  Page 72  |  Page 73  |  Page 74  |  Page 75  |  Page 76  |  Page 77  |  Page 78  |  Page 79  |  Page 80  |  Page 81  |  Page 82  |  Page 83  |  Page 84  |  Page 85  |  Page 86  |  Page 87  |  Page 88  |  Page 89  |  Page 90  |  Page 91  |  Page 92