An ITS architecture can show where existing organizational structures should be changed and perhaps rather radically changed in order to deliver the desired ITS services. An example is probably a traffic control center (TCC) that may have to exchange data with another TCC or mobile information center (TIC) beyond the national or language borders. It is very important to define the content and minimum performance specification for this process. ITS architecture enables the performance specification to be defined to achieve the required level of interconnection and interoperability. Which technologies are best used as a response is an issue for the system designer.
It is not possible to present a complex system in a way that can convey all the information about the system in an understandable way. This is reflected in an ITS architecture that uses multiple perspectives that show different levels of detail and different types of information. These perspectives can include:
- logic (or functionality) of the system (“logical” or “functional” perspective) that describes how various data items should flow and be processed
- how ITS functionality will be in the physical components of the system (“physical” perspective)
- what communication is required between the physical components and between the outside world and the physical components (“communication” perspective)
- how system components, communications and responsibilities will be assigned to providers and recipients of ITS services (“corporate” perspective)
In addition to developing an architecture for ITS, there are other analysis requirements to consider:
- how components and communication can be distributed
- what will be the distribution costs and how to accounting them with benefits (cost / benefit analysis)
- Examining risks that affect the implementation and presentation of all ITS services.
- It is often important to define the system boundary to show what is outside the specific ITS application, but it is important for some functional components – for example, financial institutions such as banks, in the case of payments or electronic ticketing
Architecture Levels
AUS architectures can be divided into two levels: high-level architectures and low-level architectures. This is not something ITS specific, the distinction generally applies to the use of system architectures.
In the context of Intelligent Transportation Systems, it is the conceptual design that defines the structure and / or behavior of a high-level architectural system. ITS specifies the functionality required to provide user services – technical specifications are independent and the choice of individual components and communication is left open. This technology independence means that suppliers have the freedom to choose the most appropriate technical solution for the customer while still adhering to the overall architecture.
On the contrary, low level (or component) architectures include actual designs for hardware, software, data exchange and communication. They narrowly define the necessary technologies, including the use of ITS standards. (See ITS Standards) If they have expertise, a low-level architecture can be developed by the commissioning agency, but it is more common to develop design specifications from a high-level architecture by the system integrator or system supplier. (See Systems Engineering)
Advice for Operators
There are two types of high-level ITS architectures, a framework architecture and a ‘model’ architecture that provides two basic but different approaches that form the basis for the development of ITS architectures, both in common use and adaptable worldwide. Some of these ITS architectures may be specific to a class ITS application. This is becITSe it supports the implementation of a particular service, such as traffic control centers, parking lot management or public transport fleet management.
