CON4COORD WP4 Road Network Control - Design and High Level Specification

C4C Deliverable FP7-ICT-2007.3.7.(c) grant agreement nr. INFSO-ICT-223844 CON4COORD WP4 Road Network Control - Design and High Level Specification Jos Vrancken Frank Ottenhof, René K. Boel, Jan H. van Schuppen, Leandros Tassiulas Title CON4COORD WP4 Road Network Control - Design and High Level Specification Authors Jos Vrancken Frank Ottenhof, René K. Boel, Jan H. van Schuppen, Leandros Tassiulas Main participant TUD, TRI, UGE, CWI, CER Deliverable nr D-WP4-2 Version 1.0 Date May 14, 2009

Abstract This document is deliverable D-WP4-2 for Work Package 4 RON on Road Network Control in the C4C (Con4Coord) project. TEXT Contents 1 Introduction 3 2 WP4 Teams 3 2.1 Team collaboration in the reporting period..................... 3 3 WP4 Description 4 3.1 Research Objectives.................................. 4 4 WP4 Overview of Results in the reporting period 4 4.1 Architecture....................................... 4 4.2 System development methodology.......................... 5 4.3 Tool development.................................... 5 4.4 Monitoring....................................... 5 4.5 Control......................................... 5 4.6 Standardization..................................... 6 5 WP4 Research plan for the coming year 6 6 Concluding remarks 6 7 Appendix A, the design document for WP4 8 2

1 Introduction This document is the deliverable D-WP4-2: Design and high level specification, i.e. the second deliverable for WP4 RON: Road Network Control of the FP7 project CON4COORD, often referred to as C4C. The document covers the period from May 1, 2008 through April 30, 2009, i.e. the first year of the C4C project. The design document is included as appendix A, preceded by an explanatory note. This document is about the project context in which the design was developed. It describes the teams involved, the results obtained in the first year and the research plan for the coming period of one year. At the end a list of references is included containing the WP4-related publications, produced by the teams involved, in the past year. 2 WP4 Teams The following teams are involved in WP4, in the order of the number of person months (pm) of their involvement: 1. TUD: TU-Delft 21 pm; 2. TRI, Trinité Automatisering B.V., 16 pm; 3. UGE, Universiteit Gent, 8 pm; 4. CWI, Stichting Centrum voor Wiskunde en Informatica, 6 pm; 5. CER, Center for Research and Development, Hellas, 1 pm. TUD The TUD team belongs to Delft University of Technology, faculty of Technology, Policy and Management. In the report period is has been extended with two PhD students. It now consists of senior researcher Jos Vrancken, team leader and leader of WP4, Michel dos Santos Soares, Phd student, for half of his time on the project since May 1, 2008, Yufei Yuan, PhD student on the project since September 1, 2008, and Mohsen Davarynejad, PhD student on the project since January 1, 2009. The TUD team has a close collaboration with the group of Prof. Hoogendoorn at the faculty of Civil Engineering of TU-Delft. This group specializes in Dynamic Traffic Management. They are not formally involved in WP4, but the research they do is highly relevant. Yufei Yuan is a shared PhD student with Hoogendoorn s group. TRI The TRI team belongs to the company Trinité Automatisering B.V. in Uithoorn, The Netherlands. It consist of Frank Ottenhof, General Manager of Trinité, Marcel Valé, senior project leader and team leader of the TRI team and Yubin Wang, senior developer. Yubin Wang is also appointed at TU-Delft as a PhD student. UGE The UGE team belongs to Universiteit Gent in Belgium. It consists of senior researcher and UGE-team leader René Boel, postdoctoral researcher Jonathan Rogge and the PhD students Nicolae Marinica, Herman Sutarto and Mohammad Moradzadeh. CWI The CWI team belongs to the Stichting Centrum voor Wiskunde en Informatica. Of the team members, only the team leader, Jan H. van Schuppen is regularly involved in WP4. CER The CER team belongs to the Center for Research and Development Hellas, in Greece. Its involvement in WP4 is limited and will take place in the final year of the project. 2.1 Team collaboration in the reporting period Team collaboration has been as follows. The teams TUD and TRI collaborate on a daily basis, with Wang regularly visiting TU-Delft and Davarynejad working half of his time at Trinité in Uithoorn. Joint team meetings take place at least once a month. The collaboration between 3

TUD and UGE is less intense. In June 2008, the two team leaders have agreed on relatively independent tasks for which contacts att the three joint project meetings were mostly sufficient. This may change in the coming two years, when results of the UGE team are going to be implemented in the TRI systems. The collaboration between TUD and CWI consisted of several meetings between the two team leaders, mainly dealing with theoretical modeling tasks. 3 WP4 Description 3.1 Research Objectives The original objectives as stated in the C4C project proposal were: 1. Control principles for network control; 2. Improving the operational HARS network control system on the Alkmaar beltway; 3. Developing a simulator for HARS; 4. Developing a network monitoring system for measuring the effects of HARS; 5. Developing a systems development methodology for traffic management systems. In other words, WP4 aims at improving the way road operators do network management, and at improving the systems supporting the road operators. Emphasis in the approach is on operational systems, in addition to lab simulations, and on advanced systems development methods in order to give operational systems the flexibility that research with these systems requires. The objectives are for the most part still valid. Because of the dependence on operational systems, there is a strong dependence on the commissioning parties involved. Recently attention has therefore shifted from the HARS system in Alkmaar to a control system to be installed on the A10 beltway of Amsterdam. But the traffic engineering objectives remain the same for both systems. 4 WP4 Overview of Results in the reporting period In the reporting period, the following results have been obtained, which are grouped in a number of themes (i.e. not by team but by theme). 4.1 Architecture At the architecture level, which involves both traffic and systems engineering aspects, a hierarchical model for network monitoring has been developed, in cooperation with the CWI team [10][9]. For systems development, the Kruchten 4+1 architecture [6] has been considered for integration with other specification formalisms that are useful for real-time process control in the context of traffic control applications. This has been done by the TUD and TRI teams. A system architecture detailing the different layers of a distributed controller for urban road traffic has been proposed by the UGE team. [3]. This involves different layers for describing the interaction between the local control agents (one control agent per intersection). The strategic planning layer will assign different modes of operation (with various levels of local optimization and various levels of intelligent coordination between neighboring agents) depending on the traffic intensity and the reliability of the data. 4

4.2 System development methodology For real-time process control systems, there are a number of development methods currently available that all serve a useful purpose in this area, but that are not well integrated. The combined use of these methods remains problematic. This is felt most in the architecture, the user requirements and the verification phases of system development. To improve this, the integration of SysML, Kruchten 4+1 architecture, the Model Driven paradigm and, for verification, Petri nets have been considered. A method has been proposed, [6], that integrates all of these components. In order to test the method in practice, a three day course has been given on this method at Trinité. The model driven paradigm has been applied to user requirements specification [5]. Petri net modeling and verification has been applied to traffic signals [7] in urban traffic control. 4.3 Tool development The activities in this theme are concerned with improving and extending the system development environment at Trinité, primarily with tools that make possible the application of the theoretical research results in the traffic engineering domain of WP4. The core of the Trinité environment consists of a Publish/Subscribe-type of middleware, called DSS, which allows the flexible combination of different system components, while maintaining real-time properties in communication. The following tools have been implemented on top of DSS: A visualization tool for monitoring data [8]; Road network representation generator [13]; Migration of the Fastlane first-order, multi-class traffic simulator, from Mathlab to C++ on DSS (no publication yet); 4.4 Monitoring The activities in this theme have been focused on improving traffic monitoring, both locally and at the network level. At the network level, the aforementioned hierarchical model has been applied to organize the derivation of network level data from local measurements [11]. For local measurements, combinations of known filtering techniques (Kalman and Treiber/Helbing) have been considered [14] to improve noise reduction and to make up for missing physical sensors. For detection of traffic accidents and detection of sensor failures, probabilistic methods based on free choice Petri nets have been studied [2] by the UGE team. This team has also studied ways to detect platoons in traffic to which signal control strategies can be applied. 4.5 Control In the area of network control, the question has been studied how combinations of top-down and bottom-up control can be implemented in the DSS environment, following the hierarchical model mentioned earlier [12]. Coordinated ramp metering looks promising for being applicable in the near future on the A10 beltway in Amsterdam. Therefore, this problem has been studied in a simulation environment in preparation of real-life implementation [15]. An inventory has been made of fuzzy control mechanisms. These have been applied in the past to local control problems, but they look promising for network control as well [1]. For urban control, groups of intersections have been considered, both controlled and without controls (traffic circles), for coordinated control. 5

4.6 Standardization For the practical implementation of network control, often involving different local systems from different manufacturers, the level of standardization in traffic control has to be increased. The TRI team has put effort into creating awareness of this problem and has put forward an approach towards standardization using the ideas developed in this project. For the time being, this is limited to the Dutch traffic management market [4]. 5 WP4 Research plan for the coming year In the coming period, WP4 continues with gradual, stepwise progress in most of the areas mentioned in the previous section, and with combining theoretical work with practical, real-life implementations. Only the area of systems development methodology will probably become less active. The focus there will be primarily on implementing the proposed method at Trinité. In more detail: The Fastlane simulator will be integrated into the HARS system, replacing the original simulator, which functioned unsatisfactorily in this system. It will serve the purpose of improving the monitoring, but also the purpose of doing model predictive control. The resulting system will be the basis for the coordinated ramp metering control system planned for the A10 beltway in Amsterdam. The TUD team will study the coordination of ramp metering systems with the adjacent traffic signaling systems. Work will continue on filtering techniques for improved monitoring, especially for networkrelated quantities such as turn fractions at sections and origin-destination matrices. In the control area, the TUD and TRI teams will be working on decision support systems for traffic operators, i.e. systems in which the effects of proposed control measures can first be tested by simulation before the measures are put into effect. These teams will also put much effort into evaluating and improving the bottom-up control mechanism present in the HARS system. The UGE team will study a number of subjects in monitoring and control using platoon based models of traffic. It will validate this kind of models using a large available data set. This will be applied to the coordination problem of groups of near-by controlled and uncontrolled urban intersections. The control methods proposed by the UGE team will be considered for implementation in the Trinité environment and may contribute to the A10 system. 6 Concluding remarks In the past year, WP4 has been successful in hiring PhD candidates, in making some theoretical progress, both in monitoring and in control, and in improving its position in real-life implementations when the TRI team managed to acquire the A10 beltway assignment. An important challenge for the coming year will be to test the flexibility of the Trinité environment by incorporating the monitoring and control methods developed, relatively independently, by the UGE team. 6

References [1] Mohsen Davarynejad and Jos Vrancken. A survey of fuzzy set theory in intelligent transportation: State of the art and future trends. In Proceedings of The 2009 IEEE International Conference on Systems, Man and Cybernetics, 2009. submitted. [2] Jana Flochova and René K. Boel. On fault diagnosis of random free-choice petri nets. In Proc. of 7th IFAC Symposium on Fault Detection, Supervision and Safety of Technical Processes. IFAC, Barcelona, Spain, 2009. [3] Nicolae Marinica and René Boel. Distributed control of urban traffic networks using hybrid models. In Proc. of the 28th Benelux Meeting on Systems and Control, 2009. paper number 242. [4] Frank Ottenhof, Marcel Valé, and Jos Vrancken. Services in netwerkmanagement. In DVM Symposium, 2009. in Dutch, submitted. [5] Michel S. Soares and J.L.M. Vrancken. Model-driven user requirements specification using sysml. Joural of Software, 3(6):57 68, June 2008. [6] Michel S. Soares and J.L.M. Vrancken. Including sysml in the 4+1 view model of architecture for software-intensive systems. In Proceedings of CSER 2009, Loughborough, 2009. accepted. [7] Michel S. Soares and Jos Vrancken. Responsive traffic signals designed with petri nets. pages 1942 1947, Oct. 2008. [8] Michel S. Soares, Jos Vrancken, and Yubin Wang. Application of a publish-subscribe middleware for road traffic measurements visualization. In Proceedings of The 2009 IEEE International Conference on Networking, Sensing and Control, pages 329 333. IEEE IC- NSC, IEEE, March 2009. [9] J.L.M. Vrancken, J.H. van Schuppen, Michel S. Soares, and Frank Ottenhof. A hierarchical model and implementation architecture for road traffic control. In Proceedings of The 2009 IEEE International Conference on Systems, Man and Cybernetics, 2009. [10] J.L.M. Vrancken, J.H. van Schuppen, Michel S. Soares, and Frank Ottenhof. A hierarchical network model for road traffic control. In Proceedings of The 2009 IEEE International Conference on Networking, Sensing and Control, 2009. [11] Jos Vrancken, Michel S. Soares, and Frank Ottenhof. A real-life test bed for multi-agent monitoring of network performance. In Proceedings of the International Conference on Infrastructure Systems, pages 1 7, 2008. [12] Yubin Wang, Michel S. Soares, and Jos Vrancken. Intelligent network traffic control by integrating top-down and bottom-up control. In Proceedings of the Chinese Control & Decision Conference, 2009. accepted. [13] Yubin Wang, Jos Vrancken, and Michel S. Soares. Road network representation using dijkstra s shortest path algorithm. In Proceedings of IFAC Symposium on Transportation Systems, 2009. submitted. [14] Yubin Wang, Yufei Yuan, and Jos Vrancken. Traffic parameter estimation on motorway networks by combination of filtering techniques. In Proceedings of The 2009 IEEE International Conference on Systems, Man and Cybernetics, 2009. submitted. 7

[15] Yufei Yuan, Jos Vrancken, W Daamen, and Serge Hoogendoorn. Coordinated ramp metering:a case study with the hero algorithm. In ITS World Congress Stockholm, 2009. accepted. 7 Appendix A, the design document for WP4 The appended document Software Design Description, Sarad, Control for Coordination is the current design document for WP4. It is an internal document of Trinité Automatisering B.V. It covers the architectural design and high level specification of the network monitoring and control system, embedded in Trinité s software environment. 8

S F 2 2 4 e S A R A D Software Design Description, SARAD Control for Coordination (C4C)

Document informatie Document: Document Omschrijving Project TRI-INTERN Document 090303-YW-D01-R04-SARAD C4C Revisie 0.5 Samensteller Yubin Wang Revisie: Nummer Omschrijving Datum Paraaf Initialen Datum x Interne release dd-mm-jjjj YW 24/02/09 0 Ter beoordeling dd-mm-jjjj A Ter beoordeling dd-mm-jjjj B Ter keuring dd-mm-jjjj C As builts dd-mm-jjjj Status: Attentie Status Datum Paraaf Deze pagina wordt bijgewerkt na elke wijziging van het document. [ ] Ter beoordeling [ v ] Ter keuring [ ] Geaccepteerd voor uitvoering [ ] As built [ ] Vervallen [ ] Onbeheerde kopie Geaccordeerd Personen Datum Paraaf Copyright 2008 Trinité Automatisering. All rights reserved. No part of this document may be reproduced or copied by any means, graphic, electronic or mechanical, including photocopying, recording, taping or information retrieval systems (microfilm), for any reason without explicit written permission from the author Copyright 2009 Trinité Automatisering B.V. Project: TRI-INTERN Pagina 2 van 36

Inhoudsopgave 1. SCOPE...5 1.1 Identificatie...5 1.2 System overview...6 1.3 Documentoverzicht...7 1.3.1 Goal of SARAD...7 1.3.2 Document structure...7 1.3.3 Reading instructions...7 1.3.4 Security and intellectual property...7 2. EXTERNAL DOCUMENTS...8 2.1 Documents...8 2.1.1 System documents...8 2.1.2 Standards...8 2.2 Informatieve documenten...8 3. SYSTEM DESIGN DECISIONS...9 3.1 Standards...9 3.2 Requirements C4C...9 3.2.0.1 Traceability requirement...10 4. SYSTEM-ARCHITECTURAL DESIGN...11 4.1 Logical architecture...11 4.1.1 Objects in C4C...12 4.1.1.1 Objects in C4C...12 4.1.1.2 NMRoad Object...13 4.1.1.3 Prediction model (fastlane or quaidao)...14 4.1.1.4 Dynamical OD matrix estimation...15 4.1.1.5 Control Measures...15 4.2 Implementation architecture...17 4.3 Physical architecture...18 4.4 Process architecture...19 4.4.1 The internal (standard) DSS process...19 4.4.2 Process overview: NMRoad...19 4.4.3 Process overview: Prediction model (Fastlane or quaidao)...20 4.4.4 Process overview: O-D Matrix...21 4.5 Scenario's...23 4.5.1 Scenario's NMRoad, dymatical OD matrix, Prediction model...23 4.5.1.1 NMRoad...23 Copyright 2009 Trinité Automatisering B.V. Project: TRI-INTERN Pagina 3 van 36

4.5.1.2 Prediction model NMLINK...24 4.5.1.3 Dynamical OD matrix...25 4.5.2 Scenario's errors handling...26 5. GEBRUIKTE AFKORTINGEN...27 6. INTERFACE REQUIREMENTS SPECIFICATIONS (IRS) APENDIX...28 6.1 IRS Appendix Traffic-Sensor Monitoring...28 6.1.0.1 Public signal()...28 6.1.0.2 Private Monitoring_links()...28 6.2 IRS bijlage Notifications and LOG INFO...28 6.3 IRS bijlage Maintenance...28 Lijst van tabellen. Tabel 1 Gebruikte afkortingen. 26 Tabel 2 Public Actions 27 Tabel 3 Private Actions 27 Lijst van figuren. Figuur 1 Implementation architecture 17 Figuur 2 physical architecture 18 Figure 3: Procedures of monitoring system 19 Figure 4: Procedures of prediction model (FastLane) 20 Figure 5: Procedures of dynamic OD matrix 21 Copyright 2009 Trinité Automatisering B.V. Project: TRI-INTERN Pagina 4 van 36

1. Scope This document describes the design of C4C project and the consistency with DSS objects which have already implemented. In this SARAD, we mainly consider about the phase 1 of the C4C project for the purpose of DVM symposium. In the phase 1, only a stretch of straight free way will be considered for state estimation and only personal cars will be considered for prediction model. In the future, both free way and urban road will be considered for state estimation and multi-class (Both personal cars and tracks) will be considered for prediction model. The main goal of the project is to improve traffic control system, more specifically, to improve monitoring system, prediction model and the coordination of local measures. The current traffic information are raw data from local sensors. They might have lots of error data and missing data. The monitoring system applying correction/filtering techniques will contribute solving the problems. The current MADAM system provides incorrect traffic information which causes problems to show correct information on DRIPs. The prediction model will contribute solving the problem. OD matrix will give current and predicted OD values to improve the performance of control scheme. Five PHDs will be involved in this project as the following figure. real traffic system traffic actuators ( b) state prediction ( a) state estimation traffic sensors (c) optimization goals Prediction Model initial state state estimation / data fusion optimiz e DTM measure s input: OD matrices, capacity constraints, network specs, etc Copyright 2009 Trinité Automatisering B.V. Project: TRI-INTERN Pagina 5 van 36

1.1 Identificatie Document identificatie: 090303-YW-D01-R04-SARAD C4C.odt 1.2 System overview This document describes the functional working of management system for the C4C project and defines, associated information element functionality (IE). The document serves as a basis for the technical design. The document services as the basis of the techinical design. The is consisted of the following components: Trivision VBA (Verkeer-BeheerSysteem) of Trinité Automatisering BV; DSS and TrafficLink NM Traffic sensors objects State Estimation/data fusion in NMRoad object Origin-destination (OD) matrix estimation in ODMatrix object Prediction model in NMLINK Traffic actuators objects DTM Measures. Trivision VBA Traffic Sensors State Estimation/ data fusion DSS / TrafficLink NM DTM Measures Traffic Actutors Prediction model OD Matrix Estimation DOMAIN SARAD Copyright 2009 Trinité Automatisering B.V. Project: TRI-INTERN Pagina 6 van 36

1.3 Documentoverzicht 1.3.1 Goal of SARAD The SARAD, possibly completed with IRS's and SRD's, are used as a basis for further system development. There where SARAD written state in these can be read as functional design 1.3.2 Document structure The document has been classified as follows: Section 1 describes the scope, identification, goal and usage of the document; Section 2 describes other documents; Section 3 describes requirements; Section 4 describes the qualification provisions; Section 5 describes deduction of the requirements; Section 6 describes acronyms, abbreviations and terms. 1.3.3 Reading instructions In the case of possible inconsistance between this document and Sarad, the text of this document will be taken into consideration primacy. [1] A requirement is indicated by an identification number between brakets and it is unique within the (sub)section. [2] An indentification number can not change in following versions of a document. [3] The following notation is used to refer to a requirement in the same system.: <document>.<section>.[identification], for example: SRD.3.2.4.[2] [4] Explanations, examples and images are exclusively used for explanation aims, and contain no requirements. [5] An explanation is preceded by remark. [6] An example is preceded by E.g.:. 1.3.4 Security and intellectual property All information in the document is intellectual property of Trinité Holding BV. Copyright 2009 Trinité Automatisering B.V. Project: TRI-INTERN Pagina 7 van 36

2. External documents The document makes the basis for the module developed by Trinité Holding BV in its own management. The developed module will belong in several external projects and be used as such as a cross reference. 2.1 Documents 2.1.1 System documents 2.1.2 Standards For this SARAD, it is using the 4+1-model which is made by Phillipe Kruchten. In the model, an architecture is described from 5 (4+1) aspects : Logical overview; Development overview; Physical overview; Process overview; Scenario's (USE-cases). UML will be used as a modelling technique. 2.2 Informative document Fastlane paper: trb08_vanlint_hoogendoorn_fastlane.pdf, hvl_ifac2008_final.pdf Fastlane slides: lecture_fastlane.ppt Fastlane Matlab code explanation: FastLane.doc Data fusion: TRB_2008_serge fusion v2.doc C4C project plan: C4C-WP4-projectplanv2.pdf All the documentation can be found from directory: /adminhome/trinite/producten/nm/c4c Copyright 2009 Trinité Automatisering B.V. Project: TRI-INTERN Pagina 8 van 36

3. System design decisions 3.1 Standards The most important decisions are dictated by the design decisions which aim at in general applying for DSS systems: the resources of the system is not unnecessarily to change; the system should free to add new functionality correctly and reliably future adaptations/improvement to simplify trouble shooting at jamming and debug as efficient as possible to finish The most important decisions are: 1. design as many event driven possible, therefore no unnecessary traffic data 2. also like to take fault-moments of system components into account 3. always as much as possible to abstract to generic functionality or tries the switch-over to specific as long as possibly to postpone. 4. at the design stage has already taken many future extensions as consideration 5. DSS has standard way for debugging. The chance to discretion is put to or from. So much possibly debug-information. 3.2 Configuration maintenance The whole environment must be (re)buildable from a database in which all configuration data is available. The database must contain all the tables with the configuration data of all the components. 3.3 Requirements C4C Specifically for producing objects in C4C the following demands are made: 1)Prediction model: Adjacent area connect boundary Prediction horizon (10 minutes) for each link per minute Reducing the number of communication between links Calculation Parameters must be known: Turn fraction, Truck percentage Inflow and supply must be known. Prediction horizon in links are synchronized 2)Monitoring: To define a stretch of road with sensors position (Automatically) Able to define more stretch of road for whole network Complete data for the stretch of road. Correct data for the stretch of road. Copyright 2009 Trinité Automatisering B.V. Project: TRI-INTERN Pagina 9 van 36

Can handle all kinds of sensors. Output should be segments based. Assign output data to distribute segments Calculate the parameters of the Fundamental Diagram Current position and the predicted position of the Shock wave. Segment based event (incident) detection Store Historic data 3.3.0.1 Traceability requirement nr Description Origin Processes in paragraphs 1 Adjacent area connect boundary Interview 4.4.3 2 Prediction horizon (10 minutes) for each link per minute 3 Reducing the number of communication between links 4 Calculation Parameters must be known: Turn fraction, Truck percentage Interview 4.4.3 Interview 4.4.2 Interview 4.4.3 5 Inflow and supply must be known. Interview 4.4.3 6 Prediction horizon in links are synchronized Interview 4.4.3 7 To define a stretch of road with sensors position (Automatically) 8 Able to define more stretch of road for whole network Interview 4.4.2 Interview 4.4.2 9 Complete data for the stretch of road Interview 4.4.2 10 Correct data for the stretch of road. Interview 4.4.2 11 Can handle all kinds of sensors Interview 4.4.2 12 Output should be segments based Interview 4.4.2 13 Assign output data to distribute segments Interview 4.4.2 14 Calculate the parameters of the Fundamental Diagram 15 Current position and the predicted position of the Shock wave Interview 4.4.2 Interview 4.4.2 16 Segment based event (incident) detection Interview 4.4.2 17 Store Historic data Interview 4.4.2 Copyright 2009 Trinité Automatisering B.V. Project: TRI-INTERN Pagina 10 van 36

4. System-architectural design 4.1 Logical architecture Logical architecture (LA) gives an overview of the functional requirements to which must satisfy the system (and then particularly the services which the system must offer the users to fill in these requirements). The system is subdivided in important abstractions, generally from the problem field directly originating, which is reflected in the form objects or object classes. Been called in, this way, class diagrams the objects and their logical relation are reflected. The specific interpretation of an object (state transition diagrams, properties etc.) is reflected in the SRD of the concerning object. The objects are in principle identified on the basis of linguistic analysis, what contents that the nouns in the process diagrams are commented, etc., in principle as a potential object. By means of next reference architecture it is vervolgens stipulated if an object belongs to company logic: Presentation (interactions with the users) Business (business-logic of the application) Data (primary fact layer) The identified objects are set out in the application software with an English denomination. Copyright 2009 Trinité Automatisering B.V. Project: TRI-INTERN Pagina 11 van 36

4.1.1 Objects in C4C 4.1.1.1 Objects in C4C The objects in C4C contains the following object diagram: OD MATRIX Control Scheme ODMGR DTM Measures * NMROUTE DTM Measures JUNCTION NMLINK Prediction model DTM Measures Segment NMRoad Sensors Monica The overview of the objects and their connections are given in the above figure. Each sensor object receives raw date from Monica and pass the raw data to NMRoad object. Advanced filtering technique (such as Treiber filter) is applied in the NMRoad object to clean and complete data for each NMSEGMENT object and then the information of each NMSEGMENT object passed to NMLINK. NMLINK object stores the received data in SEGMENTSHEET. At the mean time, NMRoad can detect incident by comparing the raw data and clean data. The prediction model is also in NMLINK. So the NMLINK object can predict the traffic situation for the prediction horizon (lets say next 10 minutes). It can be used for DTM Measures. Copyright 2009 Trinité Automatisering B.V. Project: TRI-INTERN Pagina 12 van 36