- Email: [email protected]
Embedded Applications in the Paris Buses
Copyright 10 IFAC Intelligent Components and Instruments for Control Applications, Annecy, France, 1997
EMBEDDED APPLICATIONS IN THE PARIS BUSES L. Humbert* - E. Rondeau* - T. Divoux* - L. Roulet** *CRAN: Research Center for Automatic Control of Nancy URA DO fr821 ofCNRS BP 239 54506 VANDOEUVRE LES NANCY CEDEX E-Mail: [email protected]
** RATP : Regie Autonome des transports Parisien DepartementSIT 102 Esplanade de la Commune de Paris NOISY LE GRAND
Abstract: The automotive network allows the standardised information sharing between different equipments in a vehicle. The RATP company has decided to use this kind of network to manage the embedded equipments in its buses. In this framework. CRAN laboratory and RATP company have concluded a contract to specify RATP applications. CRAN has defined the different tasks to achieve by using analysis methods such as SADT and MERISE. An experimental platform is developed gathering a particular device and a V AN network to validate the study. This work is a guideline in the new development of the RATP specific applications in the Parisian buses. Keywords: Embedded systems, Fieldbus, Information system, Communication systems, Vehicles.
In this framework, the CRAN (Research Center for Automatic Control of Nancy) and the RATP company have concluded a contract in order to make optimal .choices regarding previous criteria (Humbert et al, 1995).
1. INTRODUCTION Vehicles nowadays include more and more electronic components, for instance the AntiBlocking Systems, the electronic injections, or the board computers. This leads to increase informations to manage in a vehicle. Thus, it is important to organise and to structure these informations in order to be able to quickly access to them. This trend is more complex in the public transport context, because these particular vehicles contains other equipments which are specifics to the passenger management allowing for example to check the tickets, the security and so on...
At first, this paper presents the bus internal structure and the new RATP considerations for improving the management of buses. Then, the CRAN survey is described and an experimental application is shown.
2. THE PARIS URBAN TRANSPORT PRESENTATION RATP (Regie Autonome des Transports Parisiens) accommodates about 2,4 milliards people per years using different kind of transport means : the underground (200 km), the high-speed suburban branch (114 km), the buses and the tramway (more 2600 km). So, the efficiency of this company gready conditions social and economic aspects of the French capital. It implies a continuous pursuit of structural, organisational, and technological improvements.
So, the interconnection of these components which have to interact with other components, becomes difficult. Thus, it is necessary to implement solutions based on local area network which allow both to easily share informations and to reduce the cabling costs (pSA. 1995). The Paris urban transport company (RATP) confronted to these problems, wishes to have a new communication architecture in its buses by taking into account the standardised embedded networks which now emerge such as CAN (Controller Area Network), V AN (Vehicle Area Network),...
RATP company manages about four thousand buses. A network developed by the RATP engineers is located into each bus. This network is based on the RS485 standard. The driver control panel, which is
101
3. BUS SYSTEM STUDY
the network master node, controls all the RATP proprietary components (slave nodes) connected to this network. These components are : • •
• • •
•
3.1. Analysis method The embedded equipment conceptual study allows to determine the device behaviour and to deduce informations they are able to produce and exchange. Therefore, the works are organised in four parts :
the telephony radio allowing to bus drivers to communicate with the headquarters, the odometric system and the localisation radio which uses the Global Positioning System (GPS). The correlation between the two results obtained by these two systems precisely provides the bus location; the ticket machines, the passenger counter system used to control frauds, the visual and vocal systems ensuring the communication between the bus driver and the passengers, the maintenance system monitoring the whole components.
•
the functional study, based on an hierarchical decomposition, specifies the different tasks to achieve. For this, the SADT method allows to identify the bus system functions (IGL, 1989); • the informational study specifies the data, their type, their semantic and their place. For this, the MERISE data model is used (Tardieu et ai, 1983; Tabourier, 1986); • the data flow study, represented from MERISE communication models, allows to define the communication organisation; • and the implementation study which has to be based on standardised solutions.
Three kinds of defaults relative to this present architecture have been observed : The first one concerns the actuators connection because the network has not been structured from OSI (Open System Interconnection) standard model. This implies that the network functionnalities are mixed with the application functionnalities of the driver control panel. • The second one is relative to the network robustness. The network does not take into account error recovery mechanisms during the fIle transfers and does not support network management functions. • Finally, some components are not connected to the network but directly to the driver control panel by using specialised links. This induces problems for sharing informations produced by these equipments.
This paper only deals with the functional and data flow aspects which are the more significant models to understand the implementation choices towards the communication architecture. The whole specified models is representative of the new RATP bus organisation evolution.
The CRAN survey has been to take into account the existing structures of RATP bus and to propose more generics solutions. For this, the RATP bus system has been studied by using a global approach based on modelling work divided into two steps : a functional study and an informational study, before to consider an implementation choice.
The bus control junction. A bus gathers many components which are implemented either by the vehicle constructor (the native components) or by the RATP engineers. The native components can be divided into two classes:
These methodological phases correspond to a classical analysis way recommended for example in the CIM-OSA project (Vemadat, 1990; Kosanke, 1992) and has been already used in a previous contract (Rondeau et ai, 1995) between CRAN and RATP. This project has defined a new communication architecture for managing the control devices located into the Paris underground station. The interest to apply the same methodology both to the underground station and the bus environment has been to show the overlap of these two systems and also to ensure their coherence.
•
•
3.2. Bus Functional decomposition The RATP main function is to transport people between different stations using human, software and material resources. The whole functional analysis cannot be detailed in this paper. So two functions which are the more interesting are presented: the bus control function (Fig. 1), and the RATP equipment control function (Fig. 2).
•
the low-level equipments such as vehicle lights, doors, klaxon; the more sophisticated equipments such as Antiblocking system. electronic injection, ...
Finally, the A43 SADT shows the bus component control is centralised (A431 box) from the driver control panel.
The RATP equipment control function. The main function of RATP equipment are : •
102
to infonn passengers supported by the automatic billposter (A4342 box),
CON"reXT : Bus control
READER : RATP
el Action on RATP equipment I RATP eq uipment report
Action on sophisticaled equipment I sophisticaled equipment report
low-level equipment
A43
Equipment control
Fig. 1: A43 SADT· Bus equipment control AUTHOR : HUMBERT Liooel PROJECT : Transport people in buses
READER : RATP
CON"reXT : Equipment control
n A 11': • ruv/VQ~ Action on
cl
eq~~~~
RATP Specific,-.-L-___ equipment To control RATP ...._.-.;lo....._ cl equipment
......._,..-",.
Position
information sending/passengers
Price definition/ticket swnping
reaction Tariff
Ticket Contro:l~j~
Pane A434
_ _ _ _ _ _ _ _ _ _Machine ____
~
ml RATP specific equipment control
VERSION \.01
Fig. 2: A434 SADT· RATP specific equipment control • •
payment function (A4344 box) and the information function (A4343 box).
to pay travel with the ticket machine (A4343 box), to locate the bus (A4344 box).
3.3. Data flow study
The localisation function achieved from both odometric and GPS system has to allow to automatically modify the travel tariff, and to inform the passengers that the price has changed The bus position information is sent to the driver control panel which is distributed outside the bus for both the traffic management and the security headquarters. To note, the A4341 box (To control RATP equipment) has priority, in regard to the localisation function (A4342 box), to control the
The SADT models allow to express a system functional decomposition without taking into account the material aspects. In opposition, the data flow study has to consider the outline on the integration choices because, the specified exchanged messages between the embedded components depend on the system organisation. Figure 3 presents an overview of the different data flows between each component.
103
P •
LEGEtiI!
[.~ttl
R
/
MESSAgES E"9IANGf.!) ,
Fig. 3: Bus organisational model of communication
vehicle constructor has to provide these three networks and their integration. The use of either CAN or VAN networlcs is recommended because these networlcs are standardized solutions. The choice between this two networks will only depend on the marlcet trend (which will allow to reduce the connection point costs) and not on technology aspects.
3.4 implementation The proposed network architecture is based on both the previous analysis and the Prometheus project specifications (Prometheus, 1987; Serrano et ai, 1988). In this project about multiplexing standard, three levels of network has been defined: •
•
•
the low level multiplex (MUX A or body multiplex) concerns elementary equipment interconnection such as vehicle lights, klaxon, electrical windows, ...This corresponds to the low-level equipments in the SADT models. the inter-system multiplex (MUX B) uses for electronic controllers interconnection such as antiblocking system, electronic injections, board computers. This corresponds to the sophisticated equipments in the SADT models. the external multiplex (MUX C) uses for highend computing stations interconnection typically needed in the driver environment (guidance, ... ). This corresponds to the RATP equipments.
To prove the interest and the faisability of a such architecture, an experimental platform based on the V AN network is developed. This platform contains two PC cards, and a 16 input/output card connected to a V AN network, which correspond to : one PC simulating a ticket machine behaviour, one PC simulating the driver control panel behaviour, one input/output card managing physical informations such as the bus stop demand by a passenger, the passenger counter. The PC card is designed arround MHS 29C461 VAN Data Link. Controller and a Texas Instrument SN 75LBC030 line interface. So, the card is able to read/write on the VAN network and send remote request with either in frame or deferred response. At the physical level, the card allows a 250 KFS rate and to connect until twenty nodes.
The proposed solution is to implement a network dedicated to the RATP applications (MUX C) gathering both all RATP components and the driver control panel. The interest of this architecture is to avoid conflict problems with the bus constructor native component control. The driver control panel will be the gateway between the different networks : Mux A, Mux B and Mux C (Fig. 4). That means the
The input/output card controls sixteen numerical input/output lines. The I1016 electronic component distributed by SGS Thomson ensure the exchange between V AN network. and the input/output lines.
104
CEN/CENELEC about the world Transport Telematics which have compared recently the different fieldbus solutions in the public transport framework reconunands the use of FIP network. REFERENCES
AUTOMATIC IILl POSTEa
Fig. 4. Network Architecture in a bus
Humbert, L., E. Rondeau, T . Divoux, F. Lepage, (1995). Analyse des applications dediees RAlP dans les autobus, Rapport de fin de contrat N°UK5200i5. I.G.L. Technology (1989). SADT un langage pour communiquer, Edition Eyrolles. Kosanke (1992). Open system architecture (CIMOSA); an european pre-normative development In : CARs & FOF, 8th international conference on CAD/CAM, Robotics and factories of the future, pp 486-498, Metz (France). Prometheus Project (1987), Low level Protocol developpment for the car communication In 3W.G. Structure booklet. PSA (1995) Le multiplexage et l'automobile In Conference le multiplexage, Association Capteurs Mesure et instrumentation ACMI, Archamps (France). Rondeau E., T. Divoux, F. Lepage, M . Veron (1995). MMS Virtual Manufacturing Devices generation: The Paris subway example In : integrated Manufacturing Systems Engineering, (Vemadat, Ladet Ed). pp 84-98. Chapman & Hall on behalf of the International Federation for Information Processing. Serrano C, M.a. KUNG (1988). VOX: Vehicule Distributed eXecutive In : internal rapport 80NT442694. Tabourier Y., (1986). De ['autre cote de MERlSE Systemes d'information et modeles d'entrepnse, editions d'organisation. Tardieu H., A. Rochfeld, R. Coletti, (1983). lA mithode MERlSE. tome i : principes et outils editions de l'organisation. Vernadat F.B. (1990). Modelling and analysis of enterprise information systems with CIM-OSA In: Computer integrated Manufacturing, proceedings of the sixth c/M-Europe annual conference. pp 16-27.
The 110 card supports the same line interface as the PC card. The application is developed in C language. To note another platform implementing CAN network is in progress in order to compare the two solutions.
4. CONCLUSION The obtained results, concerning the first experimentation based on VAN network, show the interest of sharing informations on a single medium : the information accessibility, the system robustness and the speed resfrehment are imprOVed towards the old configuration of the RAlP bus. The major problem is to initiate the first real implementation, since : • •
the vehicle constructor has to provide an architecture as schown on the figure 4, the component constructor has to propose network interfaces.
Finally RATP has to make a choice on an embedded network. The features of all fielbuses (CAN, V AN, FIP, Profibus, LON,... ) are able to manage the RATP embedded applications. The RAlP criteria will depend on : • connection costs, • market trend, • standardisation, • and choice of the other transport companies.
It seems the CAN network is the more consensual solutions But the Technical Committee 278 of
105
EMBEDDED APPLICATIONS IN THE PARIS BUSES L. Humbert* - E. Rondeau* - T. Divoux* - L. Roulet** *CRAN: Research Center for Automatic Control of Nancy URA DO fr821 ofCNRS BP 239 54506 VANDOEUVRE LES NANCY CEDEX E-Mail: [email protected]
** RATP : Regie Autonome des transports Parisien DepartementSIT 102 Esplanade de la Commune de Paris NOISY LE GRAND
Abstract: The automotive network allows the standardised information sharing between different equipments in a vehicle. The RATP company has decided to use this kind of network to manage the embedded equipments in its buses. In this framework. CRAN laboratory and RATP company have concluded a contract to specify RATP applications. CRAN has defined the different tasks to achieve by using analysis methods such as SADT and MERISE. An experimental platform is developed gathering a particular device and a V AN network to validate the study. This work is a guideline in the new development of the RATP specific applications in the Parisian buses. Keywords: Embedded systems, Fieldbus, Information system, Communication systems, Vehicles.
In this framework, the CRAN (Research Center for Automatic Control of Nancy) and the RATP company have concluded a contract in order to make optimal .choices regarding previous criteria (Humbert et al, 1995).
1. INTRODUCTION Vehicles nowadays include more and more electronic components, for instance the AntiBlocking Systems, the electronic injections, or the board computers. This leads to increase informations to manage in a vehicle. Thus, it is important to organise and to structure these informations in order to be able to quickly access to them. This trend is more complex in the public transport context, because these particular vehicles contains other equipments which are specifics to the passenger management allowing for example to check the tickets, the security and so on...
At first, this paper presents the bus internal structure and the new RATP considerations for improving the management of buses. Then, the CRAN survey is described and an experimental application is shown.
2. THE PARIS URBAN TRANSPORT PRESENTATION RATP (Regie Autonome des Transports Parisiens) accommodates about 2,4 milliards people per years using different kind of transport means : the underground (200 km), the high-speed suburban branch (114 km), the buses and the tramway (more 2600 km). So, the efficiency of this company gready conditions social and economic aspects of the French capital. It implies a continuous pursuit of structural, organisational, and technological improvements.
So, the interconnection of these components which have to interact with other components, becomes difficult. Thus, it is necessary to implement solutions based on local area network which allow both to easily share informations and to reduce the cabling costs (pSA. 1995). The Paris urban transport company (RATP) confronted to these problems, wishes to have a new communication architecture in its buses by taking into account the standardised embedded networks which now emerge such as CAN (Controller Area Network), V AN (Vehicle Area Network),...
RATP company manages about four thousand buses. A network developed by the RATP engineers is located into each bus. This network is based on the RS485 standard. The driver control panel, which is
101
3. BUS SYSTEM STUDY
the network master node, controls all the RATP proprietary components (slave nodes) connected to this network. These components are : • •
• • •
•
3.1. Analysis method The embedded equipment conceptual study allows to determine the device behaviour and to deduce informations they are able to produce and exchange. Therefore, the works are organised in four parts :
the telephony radio allowing to bus drivers to communicate with the headquarters, the odometric system and the localisation radio which uses the Global Positioning System (GPS). The correlation between the two results obtained by these two systems precisely provides the bus location; the ticket machines, the passenger counter system used to control frauds, the visual and vocal systems ensuring the communication between the bus driver and the passengers, the maintenance system monitoring the whole components.
•
the functional study, based on an hierarchical decomposition, specifies the different tasks to achieve. For this, the SADT method allows to identify the bus system functions (IGL, 1989); • the informational study specifies the data, their type, their semantic and their place. For this, the MERISE data model is used (Tardieu et ai, 1983; Tabourier, 1986); • the data flow study, represented from MERISE communication models, allows to define the communication organisation; • and the implementation study which has to be based on standardised solutions.
Three kinds of defaults relative to this present architecture have been observed : The first one concerns the actuators connection because the network has not been structured from OSI (Open System Interconnection) standard model. This implies that the network functionnalities are mixed with the application functionnalities of the driver control panel. • The second one is relative to the network robustness. The network does not take into account error recovery mechanisms during the fIle transfers and does not support network management functions. • Finally, some components are not connected to the network but directly to the driver control panel by using specialised links. This induces problems for sharing informations produced by these equipments.
This paper only deals with the functional and data flow aspects which are the more significant models to understand the implementation choices towards the communication architecture. The whole specified models is representative of the new RATP bus organisation evolution.
The CRAN survey has been to take into account the existing structures of RATP bus and to propose more generics solutions. For this, the RATP bus system has been studied by using a global approach based on modelling work divided into two steps : a functional study and an informational study, before to consider an implementation choice.
The bus control junction. A bus gathers many components which are implemented either by the vehicle constructor (the native components) or by the RATP engineers. The native components can be divided into two classes:
These methodological phases correspond to a classical analysis way recommended for example in the CIM-OSA project (Vemadat, 1990; Kosanke, 1992) and has been already used in a previous contract (Rondeau et ai, 1995) between CRAN and RATP. This project has defined a new communication architecture for managing the control devices located into the Paris underground station. The interest to apply the same methodology both to the underground station and the bus environment has been to show the overlap of these two systems and also to ensure their coherence.
•
•
3.2. Bus Functional decomposition The RATP main function is to transport people between different stations using human, software and material resources. The whole functional analysis cannot be detailed in this paper. So two functions which are the more interesting are presented: the bus control function (Fig. 1), and the RATP equipment control function (Fig. 2).
•
the low-level equipments such as vehicle lights, doors, klaxon; the more sophisticated equipments such as Antiblocking system. electronic injection, ...
Finally, the A43 SADT shows the bus component control is centralised (A431 box) from the driver control panel.
The RATP equipment control function. The main function of RATP equipment are : •
102
to infonn passengers supported by the automatic billposter (A4342 box),
CON"reXT : Bus control
READER : RATP
el Action on RATP equipment I RATP eq uipment report
Action on sophisticaled equipment I sophisticaled equipment report
low-level equipment
A43
Equipment control
Fig. 1: A43 SADT· Bus equipment control AUTHOR : HUMBERT Liooel PROJECT : Transport people in buses
READER : RATP
CON"reXT : Equipment control
n A 11': • ruv/VQ~ Action on
cl
eq~~~~
RATP Specific,-.-L-___ equipment To control RATP ...._.-.;lo....._ cl equipment
......._,..-",.
Position
information sending/passengers
Price definition/ticket swnping
reaction Tariff
Ticket Contro:l~j~
Pane A434
_ _ _ _ _ _ _ _ _ _Machine ____
~
ml RATP specific equipment control
VERSION \.01
Fig. 2: A434 SADT· RATP specific equipment control • •
payment function (A4344 box) and the information function (A4343 box).
to pay travel with the ticket machine (A4343 box), to locate the bus (A4344 box).
3.3. Data flow study
The localisation function achieved from both odometric and GPS system has to allow to automatically modify the travel tariff, and to inform the passengers that the price has changed The bus position information is sent to the driver control panel which is distributed outside the bus for both the traffic management and the security headquarters. To note, the A4341 box (To control RATP equipment) has priority, in regard to the localisation function (A4342 box), to control the
The SADT models allow to express a system functional decomposition without taking into account the material aspects. In opposition, the data flow study has to consider the outline on the integration choices because, the specified exchanged messages between the embedded components depend on the system organisation. Figure 3 presents an overview of the different data flows between each component.
103
P •
LEGEtiI!
[.~ttl
R
/
MESSAgES E"9IANGf.!) ,
Fig. 3: Bus organisational model of communication
vehicle constructor has to provide these three networks and their integration. The use of either CAN or VAN networlcs is recommended because these networlcs are standardized solutions. The choice between this two networks will only depend on the marlcet trend (which will allow to reduce the connection point costs) and not on technology aspects.
3.4 implementation The proposed network architecture is based on both the previous analysis and the Prometheus project specifications (Prometheus, 1987; Serrano et ai, 1988). In this project about multiplexing standard, three levels of network has been defined: •
•
•
the low level multiplex (MUX A or body multiplex) concerns elementary equipment interconnection such as vehicle lights, klaxon, electrical windows, ...This corresponds to the low-level equipments in the SADT models. the inter-system multiplex (MUX B) uses for electronic controllers interconnection such as antiblocking system, electronic injections, board computers. This corresponds to the sophisticated equipments in the SADT models. the external multiplex (MUX C) uses for highend computing stations interconnection typically needed in the driver environment (guidance, ... ). This corresponds to the RATP equipments.
To prove the interest and the faisability of a such architecture, an experimental platform based on the V AN network is developed. This platform contains two PC cards, and a 16 input/output card connected to a V AN network, which correspond to : one PC simulating a ticket machine behaviour, one PC simulating the driver control panel behaviour, one input/output card managing physical informations such as the bus stop demand by a passenger, the passenger counter. The PC card is designed arround MHS 29C461 VAN Data Link. Controller and a Texas Instrument SN 75LBC030 line interface. So, the card is able to read/write on the VAN network and send remote request with either in frame or deferred response. At the physical level, the card allows a 250 KFS rate and to connect until twenty nodes.
The proposed solution is to implement a network dedicated to the RATP applications (MUX C) gathering both all RATP components and the driver control panel. The interest of this architecture is to avoid conflict problems with the bus constructor native component control. The driver control panel will be the gateway between the different networks : Mux A, Mux B and Mux C (Fig. 4). That means the
The input/output card controls sixteen numerical input/output lines. The I1016 electronic component distributed by SGS Thomson ensure the exchange between V AN network. and the input/output lines.
104
CEN/CENELEC about the world Transport Telematics which have compared recently the different fieldbus solutions in the public transport framework reconunands the use of FIP network. REFERENCES
AUTOMATIC IILl POSTEa
Fig. 4. Network Architecture in a bus
Humbert, L., E. Rondeau, T . Divoux, F. Lepage, (1995). Analyse des applications dediees RAlP dans les autobus, Rapport de fin de contrat N°UK5200i5. I.G.L. Technology (1989). SADT un langage pour communiquer, Edition Eyrolles. Kosanke (1992). Open system architecture (CIMOSA); an european pre-normative development In : CARs & FOF, 8th international conference on CAD/CAM, Robotics and factories of the future, pp 486-498, Metz (France). Prometheus Project (1987), Low level Protocol developpment for the car communication In 3W.G. Structure booklet. PSA (1995) Le multiplexage et l'automobile In Conference le multiplexage, Association Capteurs Mesure et instrumentation ACMI, Archamps (France). Rondeau E., T. Divoux, F. Lepage, M . Veron (1995). MMS Virtual Manufacturing Devices generation: The Paris subway example In : integrated Manufacturing Systems Engineering, (Vemadat, Ladet Ed). pp 84-98. Chapman & Hall on behalf of the International Federation for Information Processing. Serrano C, M.a. KUNG (1988). VOX: Vehicule Distributed eXecutive In : internal rapport 80NT442694. Tabourier Y., (1986). De ['autre cote de MERlSE Systemes d'information et modeles d'entrepnse, editions d'organisation. Tardieu H., A. Rochfeld, R. Coletti, (1983). lA mithode MERlSE. tome i : principes et outils editions de l'organisation. Vernadat F.B. (1990). Modelling and analysis of enterprise information systems with CIM-OSA In: Computer integrated Manufacturing, proceedings of the sixth c/M-Europe annual conference. pp 16-27.
The 110 card supports the same line interface as the PC card. The application is developed in C language. To note another platform implementing CAN network is in progress in order to compare the two solutions.
4. CONCLUSION The obtained results, concerning the first experimentation based on VAN network, show the interest of sharing informations on a single medium : the information accessibility, the system robustness and the speed resfrehment are imprOVed towards the old configuration of the RAlP bus. The major problem is to initiate the first real implementation, since : • •
the vehicle constructor has to provide an architecture as schown on the figure 4, the component constructor has to propose network interfaces.
Finally RATP has to make a choice on an embedded network. The features of all fielbuses (CAN, V AN, FIP, Profibus, LON,... ) are able to manage the RATP embedded applications. The RAlP criteria will depend on : • connection costs, • market trend, • standardisation, • and choice of the other transport companies.
It seems the CAN network is the more consensual solutions But the Technical Committee 278 of
105