Développer, Employer, at Maintenir Une Architecture STI pour Votre Région

[ Précédente : Chapitre 3 ]

[ Suivante : Chapitre 5 ]

---

CHAPTER 4 - COLLECTE DES DONNÉES

TABLE DES MATIÈRES

4.1 Dresser l’inventaire

4.2 Établir les besoins et les services requis

4.3 Élaborer un concept d’exploitation

4.4 Définir les exigences fonctionnelles

Cette section décrit la deuxième étape du processus d’élaboration d’une architecture régionale des STI, la collecte des données.

À cette étape, les composants STI existants et prévus dans la région sont inventoriés, les rôles et les responsabilités de chaque intervenant dans l’élaboration, le fonctionnement et l’entretien de ces STI sont définis, les services de STI qui devraient être fournis dans la région sont établis, et la contribution (au niveau de la fonctionnalité) que chaque système apportera pour fournir ces services de STI est documentée.

Dans la présente section, les quatre tâches de l’étape « Collecte des données » sont décrites en détail. Chaque description de tâche commence par un résumé d’une page qui est suivi de renseignements additionnels sur le processus, de ressources et d’outils pertinents, d’une description générale des extrants connexes et d’exemples d’extrants, le cas échéant. Chaque description de tâche inclut également des conseils et des mises en garde qui témoignent des leçons apprises lors de l’élaboration de nombreuses architectures régionales des STI au cours des dernières années au Canada.

Ces tâches peuvent être exécutées en parallèle

• Dresser l’inventaire
• Établir les besoins et les services requis
• Élaborer un concept d’exploitation
• Définir les exigences fonctionnelles

Étape 2 : Collecte des Données – Dresser l’inventaire

Objectifs

• Déterminer les composants STI existants et prévus dans la région
• Sensibiliser les intervenants au sujet de ces composants

Processus - Principales activités

Préparer les données

• Localiser les données de l’inventaire qui pourraient être documentées dans des plans régionaux de STI (par ex., des plans de déploiement précoce), des études sur les STI, la documentation relative à des projets de STI, des demandes de proposition et d’autres documents pertinents

Dresser l’inventaire

• Utiliser les données sur l’inventaire recueillies pour créer un inventaire initial en mettant d’abord l’accent sur les « centres »
• Examiner l’inventaire initial avec les intervenants clés et recueillir d’autres renseignements
• Déterminer les organisations associées, leur état (existant ou prévu) et décrire brièvement chaque composant de l’inventaire
• Faire correspondre chaque composant de l’inventaire avec les sous-systèmes et les terminateurs de l’architecture des STI pour le Canada
• Utiliser la carte de l’architecture des STI pour le Canada afin d’établir les lacunes dans l’inventaire et déterminer les données permettant de combler ces lacunes

Établir un consensus

• Faciliter un examen approfondi de l’inventaire préliminaire et y incorporer les commentaires (les intervenants peuvent vérifier l’exactitude et l’exhaustivité de l’inventaire de leurs organisations)

Intrants - Sources d'information

• Intervenants
• Plans de STI et études sur les STI
• Plan de transport, plan de gestion de la congestion, plan de sécurité des véhicules, etc.

Extrant - Résultats du processus

• Inventaire des composants STI existants et prévus dans la région

4.1 Dresser l’inventaire

Chaque intervenant (organisme, compagnie ou groupe) possède, exploite ou entretient des STI dans la région. À cette étape, un inventaire complet des composants STI est dressé à partir des inventaires existants et des commentaires des intervenants.

4.1.1 Processus d’inventaire

Le processus visant à créer un inventaire des composants STI commence par la collecte des renseignements existants. Une telle collecte fournit souvent un excellent point de départ pour une définition de l’inventaire. En plus des plans, des études et des documents relatifs aux projets de STI déjà disponibles, les architectures régionales des STI, adjacentes ou qui se chevauchent, constituent une bonne source d’information sur l’inventaire. Une partie de l’inventaire des composants de ces architectures est souvent pertinente, fait gagner du temps et améliore la cohérence entre les architectures adjacentes ou qui se chevauchent. Il est préférable de dresser un inventaire partiel fondé sur ces ressources avant de mobiliser un grand nombre d’intervenants afin de tirer avantage le plus possible du temps dont ils disposent.

Quand vous dresserez votre inventaire, mettez d’abord l’accent sur les « centres », car ils sont généralement concernés par la plupart des interfaces interorganisationnelles, privées ou publiques, qui requièrent le plus d’attention. Intéressez-vous ensuite aux composants STI pour lesquels il existe certaines possibilités d’intégration, comme les véhicules et les voyageurs. Tenez compte ensuite des autres composants STI dans votre région. Les aéroports, les systèmes de gestion du patrimoine et les centres d’événements spéciaux sont des exemples de composants STI qui fournissent des possibilités d’intégration et qui devraient être incluses dans l’inventaire. Finalement, tenez compte des centres dans les régions adjacentes, comme les centres de gestion du trafic dans la province voisine. L’objectif est de déterminer les composants STI dans la région qui permettront de prendre en considération plus tard les possibilités d’intégration. À moins que votre région ait des besoins uniques, n’incluez pas des composants STI dans l’inventaire pour les gens (par ex., les employées des centres de régulation de la circulation) ou les terminateurs environnementaux. L’accent doit être mis sur les systèmes qui peuvent être intégrés. Les systèmes qui n’offrent pas de possibilités d’intégration (par ex., un feu de circulation isolé dans une localité éloignée) ne doivent pas être inclus dans l’inventaire.

En travaillant étroitement avec les intervenants à mesure que l’inventaire augmente et se précise, vous en améliorerez la qualité et vous sensibiliserez davantage les intervenants à l’égard des systèmes de transport existants et prévus dans votre région. De nombreux mécanismes peuvent être utilisés pour obtenir les commentaires des intervenants, tels que des ateliers, de petites réunions, des sondages téléphoniques, des courriels et des interactions sur le Web. Prévoyez utiliser un ou plusieurs de ces mécanismes afin de vérifier et d’améliorer votre inventaire à l’aide des commentaires émis par les intervenants. Il pourrait être utile de mobiliser, au début, des intervenants clés, puis de procéder à un examen plus approfondi, une fois votre inventaire achevé.

L’inventaire devrait couvrir la zone géographique, le calendrier et l’étendue des services dans la région. L’inventaire, qui représente des systèmes existants et des systèmes qui pourraient être mis en place au cours des dix ou vingt prochaines années, peut être élaboré d’une seule traite ou en plusieurs occasions. Par exemple, vous pourriez commencer par dresser l’inventaire des composants STI existants, puis ajouter les composants STI prévus et des composants STI qui pourraient être mis en place vers la fin du calendrier établi.

Considérations relatives à la sécurité

4.1.2 Outils et ressources

Les sous-systèmes et les terminateurs de l’architecture des STI pour le Canada peuvent servir à organiser les composants STI dans votre inventaire. Par exemple, les centres de régulation de la circulation (CRC) et les centres de communication de la sécurité publique pourraient être associés au sous-système de la gestion de la circulation et au sous-système de la gestion des urgences, respectivement. Cette association ou la correspondance avec l’architecture des STI pour le Canada établit une connexion importante entre l’architecture régionale des STI et l’architecture des STI pour le Canada. Les sous-systèmes et les terminateurs peuvent aussi servir de liste de vérification qui pourrait être utilisée pour déterminer les lacunes dans l’inventaire.

4.1.3 Extrant de l’inventaire

L’inventaire d’une architecture régionale des STI est une liste de tous les composants STI existants et prévus dans une région et des composants qui fournissent ou permettent d’obtenir des renseignements à partir des composants STI. L’accent doit être mis sur les composants qui soutiennent ou pourraient soutenir des interfaces qui traversent les limites territoriales des intervenants (par ex., des interfaces publiques, privées ou interorganisationnelles).

Il existe une grande latitude dans les types de composants STI qui pourraient être inclus et le niveau de granularité qui devrait être précisé dans l’inventaire. Bien que les inventaires varient en fonction des bases uniques des régions, des pratiques exemplaires peuvent vous aider à préparer votre inventaire.

Bien sûr, les composants STI ne peuvent pas être groupés dans des catégories générales sans discernement. De nombreux composants STI peuvent être groupés en toute sécurité dans une seule catégorie de l’inventaire, s’ils partagent les mêmes types d’information et s’ils sont déployés pour une même fonction au fil des ans. (Par exemple, les panneaux à messages sur les autoroutes et les panneaux à messages dans les abribus devraient probablement être considérés comme des composants STI distincts en raison des exigences très différentes qui leur sont associées.) Le groupement fonctionne à la Figure 5 parce que tous les dispositifs sur le terrain de Heartland font interface exclusivement avec le Centre de régulation de la circulation (CRC) de Heartland et peut, par exemple, faire partie d’un projet de déploiement d’un système unique de gestion autoroutière. Si certains composants des dispositifs sur le terrain appartenaient à un autre organisme et étaient gérés par celui-ci, il serait peut-être préférable d’établir un composant STI distinct pour ce groupe de dispositifs.

Un autre aspect dont il faut tenir compte est le fait que, quand des composants STI sont groupés dans l’inventaire général, les interfaces potentielles entre ces composants sont perdues. (Par exemple, toute interface potentielle entre les différents types de dispositifs sur le terrain de Heartland est perdue avec le groupement illustré à la Figure 5.) Ce groupement est acceptable parce que l’interface entre les dispositifs sur le terrain n’est probablement pas une interface régionale importante. La dernière question a rapport avec l’incidence que le groupement aura sur l’établissement des normes STI plus tard dans le processus. En raison du groupement, les normes STI qui soutiennent les panneaux à messages dynamiques, le contrôle des systèmes de télévision à circuit fermé (CCTV) et le contrôle des panneaux seront toutes associées à l’interface du composant combiné de l’équipement. Cela signifie que l’information sur les normes STI relative au composant doit être interprétée et utilisée avec soin pour s’assurer que les normes relatives aux dispositifs seront établies et utilisées de manière appropriée plus tard dans le processus. Dans la mesure où il est fait en tenant compte de ces questions, le groupement des composants STI, comme l’expérience récente l’indique, fera gagner du temps lors de l’élaboration de l’architecture régionale des STI, et ses effets sur la qualité et l’utilité de l’architecture seront minimes ou inexistants.

Un inventaire pourrait inclure quelques composants STI à l’extérieur de la portée définie de la région. Par exemple, l’inventaire d’une architecture provinciale des STI peut inclure un ou des composants STI représentant des centres de régulation de la circulation dans une ou des provinces adjacentes, où il existe des interfaces avec ces centres. Ces interfaces interrégionales devraient être coordonnées à travers les architectures régionales des STI afin d’éviter un chevauchement des définitions d’une même interface ou des conflits entre diverses interfaces. Les noms des composants STI dans deux architectures régionales des STI ou plus doivent être identiques quand ils représentent le même système. De même, les noms des interfaces définies dans deux architectures régionales des STI ou plus doivent être identiques quand elles décrivent le même échange d’information dans les limites de ces architectures.

Chaque composant STI dans un inventaire inclut normalement un nom, l’intervenant ou les intervenants associés, une brève description, un état général, ainsi que les sous-systèmes ou les terminateurs provenant de l’architecture des STI pour le Canada. Cette information de base peut être accompagnée de renseignements sur des emplacaments particuliers, des personnes-ressources, d’autres références et, au besoin, sur la mise en oeuvre. La région devrait déterminer l’information requise pour chaque composant de l’inventaire à partir de ses besoins et des ressources disponibles.

Les champs normalement inclus dans chaque composant d’inventaire sont décrits dans les paragraphes qui suivent.

Nom du composant : Chaque composant devrait être sélectionné en fonction de certains critères. Plus important encore, le nom sélectionné devrait pouvoir être reconnu facilement par les intervenants. De préférence, le nom d’un composant devrait être un nom usuel ou, du moins, être libellé dans des termes bien connus des intervenants.

Le fait d’inclure le préfixe de l’intervenant et le nom du système dans chaque nom de composant STI peut l’allonger beaucoup. Des abréviations et des acronymes seront utiles afin d’avoir, autant que possible, des noms de composants courts qui pourront entrer dans les diagrammes et les tableaux qui seront utilisés pour publier l’inventaire. Cependant, on doit s’assurer que toutes les abréviations et tous les acronymes sont compris par les intervenants.

Intervenants associés : Bien qu’ils puissent participer au consensus sur toute partie de l’architecture régionale des STI, les intervenants s’intéressent souvent davantage aux composants de l’inventaire qu’ils possèdent, exploitent ou entretiennent. Il est utile de documenter l’association entre les intervenants et les composants STI, puisque cela permet aux intervenants d’établir rapidement leurs propres composants. Une telle association aide les intervenants à utiliser leur temps le plus efficacement possible. Si des intervenants n’ont pas le temps d’examiner toute l’architecture régionale des STI, ils peuvent examiner les sections qui concernent l’organisme, la compagnie ou le groupe d’intérêt auquel ils sont associés.

Sous-systèmes ou terminateurs associés : Chaque composant de l’inventaire d’une architecture régionale des STI devrait correspondre à un ou plusieurs sous-systèmes ou terminateurs de l’architecture des STI pour le Canada. Cette association doit être créée parce qu’elle conduira à l’établissement des exigences fonctionnelles du composant STI, des flux architecturaux et du soutien aux normes STI lors des étapes subséquentes. Il peut arriver qu’un composant soit vraiment unique et qu’il ne corresponde à aucun sous-système ou aucun terminateur de l’architecture des STI pour le Canada. Dans ce cas, aucune association avec l’architecture des STI pour le Canada n’est créée. Il s’agit d’une approche parfaitement valide, mais cela ne signifie pas que la fonctionnalité, les flux architecturaux et les normes qui seront établis plus tard pour le composant ne trouveront pas un fondement dans l’architecture des STI pour le Canada.

4.1.4 Exemples d’inventaires

Quoique les inventaires aient tendance à inclure la même information, on peut imaginer différentes façons de documenter cette information. Voici trois exemples qui illustrent des façons différentes de documenter les inventaires.

Exemple 1 : Résumé d’inventaire trié par nom d’intervenant

Un résumé d’inventaire peut être présenté sous la forme d’un tableau, comme le montre la partie de l’architecture des STI de la région de York à la Figure 6. Puisque le tableau est trié par nom d’intervenant, les intervenants peuvent trouver facilement les composants associés à leur organisme, leur compagnie ou leur groupe d’utilisateurs. Par exemple, un employée de Georgina pourrait constater rapidement que quatre composants de l’architecture des STI sont associés à son organisme.

Exemple 2 : Inventaire présentant des renseignements détaillés

La Figure 7 montre des renseignements plus détaillés sur un composant STI (« Systèmes de transport en commun du réseau GO ») de l’architecture des STI dans la région de York. Cette figure présente l’état du composant, une brève description du composant, qui est l’intervenant qui possède ou exploite le composant, ainsi qu’une liste des sous-systèmes et des terminateurs de l’architecture des STI pour le Canada auxquels le composant correspond.

Exemple 3 : Inventaire représenté sous la forme du diagramme des sous-systèmes

L’association ou la correspondance entre les composants d’une architecture régionale des STI et l’architecture des STI pour le Canada est souvent décrite sous la forme étendue du « diagramme des sous-systèmes », comme l’illustre la Figure 8. Ce diagramme est aussi extrait de l’architecture des STI dans la région de York. Ici, le diagramme générique des sous-systèmes est étendu de manière à ce que chaque sous-système et chaque terminateur, même s’ils apparaissent normalement dans un diagramme de sous-systèmes, soient associés à des composants particuliers de l’inventaire des STI dans la région de York.

Étape 2 : Collecte des Données - Établir les besoins et les services requis

Objectifs

• Établir les besoins régionaux et les services STI qui devraient être mis en place pour répondre à ces besoins
• Établir un consensus sur les besoins régionaux et les services prioritaires

Processus - Principales activités

Se préparer

• Examiner les données sur les besoins régionaux et les services STI qui pourraient être documentés dans des plans régionaux de STI (par ex., des plans de déploiement précoce), des études sur les STI, la documentation relative à des projets de STI, des plans de transport)
• Déterminer les besoins des intervenants clés, y compris les organisations qui exploitent le système de transport, celles qui l’entretiennent et les utilisateurs

Documenter les besoins et les services

• Documenter les besoins régionaux
• Déterminer les services qui pourraient répondre à ces besoins
• Planifier et faire des examens pour établir les besoins et les services requis
• Documenter les besoins et les services requis dans la région
• Associer les services requis avec chaque composant dans l’inventaire des STI

Établir un consensus

• Établir un consensus sur les besoins et les services requis dans la région
• Axer les discussions sur les services qui requièrent un appui du groupe

Intrants - Sources d'information

• Intervenants
• Études de planification (par ex., des plans de transport, des plans de déploiement précoce, d’autres plans de STI, etc.)
• Plan de transport, plan de gestion de la congestion, plan de sécurité des véhicules commerciaux, etc.

Extrant - Résultats du processus

• Besoins régionaux et services STI requis bien documentés
• Association entre les services STI particuliers et le soutien aux composants STI dans la région

4.2 Établir les besoins et les services requis

À l’étape précédente, un inventaire des composants STI existants et prévus dans la région a été dressé. Maintenant, les services STI qui devraient être fournis par ces composants pour répondre aux besoins régionaux sont établis. Il s’agit de la première étape vers l’établissement de ce que les composants STI devraient faire demain et qu’ils ne font pas aujourd’hui. Cette étape fournit à chaque organisme l’occasion d’examiner le système de transport de la région à partir du niveau le plus élevé et de confirmer que ses buts et souhaits sont compatibles avec le reste de la communauté du transport.

4.2.1 Processus de définition des besoins et des services

Établir les besoins

Avant d’établir l’ordre de priorité des services STI dans la région, il faut bien comprendre les problèmes liés au système de transport régional et les besoins des organisations qui exploitent le système de transport, de celles qui l’entretiennent et des utilisateurs. Dans de nombreux cas, les besoins régionaux sont déjà documentés dans des études ou des plans existants. Même si les besoins de la région ne sont pas documentés officiellement, les organisations qui exploitent le système de transport, celles qui l’entretiennent et les utilisateurs les connaissent généralement. On établit les besoins en recueillant des renseignements dans des documents existants et en obtenant les commentaires des intervenants.

Les plans de STI et les plans de transport traditionnels devraient être examinés pour obtenir des renseignements sur les besoins dans la région et les services. Généralement, les plans de transport à long terme abordent les tendances sociales et économiques, ainsi que la manière dont l’infrastructure doit être bâtie pour répondre aux besoins de la région. Beaucoup de ces politiques et de ces buts sont directement reliés aux besoins et aux services qui orientent une architecture régionale des STI. Par exemple, si de nouvelles installations importantes sont prévues dans la région, il est alors approprié de prévoir ajouter des services STI. Si une région fait des investissements considérables afin d’améliorer les services de transport en commun, ces services bonifiés devraient être reflétés dans l’architecture régionale des STI.

Les besoins recueillis à partir de l’examen de la documentation peuvent être passés en revue avec les intervenants clés de la région. Il vaut mieux commencer par une liste possible de besoins quand on cherche à obtenir les commentaires des intervenants. Si des besoins régionaux n’ont pas été documentés, une liste représentative de besoins potentiels peut être utilisée afin d’entamer les discussions. À partir des commentaires émis par les intervenants, on établit les besoins de la région avant d’établir les services. Idéalement, les besoins doivent être définis avant les services STI. Mais, dans certaines situations, un processus itératif est suivi. À mesure qu’ils comprennent mieux les besoins en discutant des services STI, les intervenants peuvent documenter leurs besoins avec plus de précision.

Établir les services requis – Services aux utilisateurs et ensembles de solutions applicatives

Les services STI sont les choses qui peuvent être faites pour améliorer l’efficacité, la sécurité et la commodité du système de transport régional grâce à de meilleures données, à des systèmes perfectionnés et à de nouvelles technologies. Les services STI sont établis par ordre de priorité dans la région à partir des besoins régionaux documentés.

La première tâche consiste à déterminer la liste initiale des services STI qui seront examinés et établis par ordre de priorité. Les services STI peuvent être décrits de diverses façons, mais la plupart des listes courantes des services STI sont des « services aux utilisateurs » et des « ensembles de solutions applicatives ».

Trente-sept services aux utilisateurs couvrant un vaste éventail de besoins de transport de surface ont été définis. Les services aux utilisateurs sont généralement un énoncé de services neutre aux niveaux de la technologie et de l’architecture. Ils établissent ce qu’un système de transport régional intelligent doit faire, mais ils n’indiquent pas comment les fonctions seront attribuées aux composants STI, ni comment ces composants communiqueront entre eux pour répondre aux besoins. En fait, les services aux utilisateurs sont tout le contraire des ensembles de solutions applicatives.

Des ensembles de solutions applicatives ont été utilisés comme listes initiales de services STI par de nombreuses architectures régionales des STI. Ces ensembles fournissent une perspective axée sur les services de l’architecture des STI pour le Canada qui établit les éléments de l’architecture qui sont requis pour mettre en place un service en particulier. Il existe des raisons impérieuses d’utiliser des ensembles de solutions applicatives afin de mettre en place des services :

1. Ces ensembles sont bien documentés; ils fournissent des graphiques de haut niveau, des descriptions brèves et des définitions détaillées sur l’architecture physique des STI pour le Canada.
2. Ils offrent plus de granularité que les services aux utilisateurs, ce qui permet de faire des choix de services plus précis.
3. Le passage à Turbo Architecture est facilité lorsque des ensembles de solutions applicatives sont utilisés, puisque ce logiciel en utilise également.

Peu importe qu’on utilise au départ une liste d’ensembles de solutions applicatives ou une autre liste de services STI, il faut s’assurer que les services:

1. sont présentement fournis par les composants STI dans la région;
2. seront fournis, une fois que les projets prévus seront mis en oeuvre;
3. répondent à des besoins régionaux et pourraient être mis en place dans l’avenir.

Les commentaires des intervenants sur chacun de ces choix doivent être sollicités activement, de préférence dans un forum direct comme une séance de remue-méninges ou un atelier. Il faut garder à l’esprit que le but de cette tâche est d’établir les services STI importants. À cette étape du processus, on doit éviter de tourner en rond en se demandant comment ces services seront fournis de manière particulière.

Il est habituellement approprié d’axer les discussions sur les services qui concernent le secteur public. Les ensembles de solutions applicatives qui relèvent exclusivement du secteur privé, sans interfaces avec le secteur public (par ex., des ensembles de solutions applicatives pour la sécurité de certains véhicules autonomes) peuvent généralement être exclus.

Chaque service STI sélectionné pour la région doit être associé à un ou plusieurs composants de l’inventaire qui soutiennent ou soutiendront ce service. Chaque association doit être examinée et approuvée par les intervenants concernés par les composants STI régionaux. L’association entre les services STI et les intervenants sera le point de départ des concepts d’exploitation, qui seront définis à la prochaine tâche du processus.

4.2.2 Outils et ressources

Beaucoup de ressources portent sur les « besoins » sans le contexte des STI et de la planification du transport de surface. Les ensembles de solutions applicatives et les services aux utilisateurs sont documentés sur le site Web de l’architecture des STI pour le Canada (http://www.tc.gc.ca/innovation/sti/fra/architecture.htm), qui fournit une foule de renseignements qui peuvent soutenir la sélection des ensembles de solutions applicatives, y compris des tableaux qui relient les ensembles de solutions applicatives aux problèmes de transport et à leurs solutions, aux buts des STI et aux services aux utilisateurs. Chaque ensemble inclut un graphique, un ou plusieurs diagrammes de documents informatisés, une description, ainsi qu’une liste détaillée des sous-systèmes, des terminateurs, des ensembles de produits et des flux architecturaux.

4.2.3 Besoins régionaux et services requis (extrant)

L’extrant de cette étape du processus est une liste des besoins régionaux et des services qui seront mis en place dans la région.

Besoins

Chaque besoin doit être documenté complètement et inclure la liste des organismes ou des secteurs touchés dans la région. Par exemple, l’énoncé « atténuer la congestion dans les zones d’activité, les échangeurs routiers et au centre-ville » est préférable au simple énoncé « atténuer la congestion ». Cet élément sera utile quand viendra le temps d’assigner des services STI aux composants de l’inventaire.

Services STI

Cette documentation établit chaque service STI qui est ou sera mis en place dans la région. Par exemple, si un ensemble de solutions applicatives est utilisé, l’extrant établit le nom de l’ensemble, son état dans la région (par ex., existant, prévu ou non prévu), une liste des composants régionaux qui le mettront en place et des notes particulières sur la personnalisation de l’ensemble de solutions applicatives ou des questions qui lui sont associées. Certaines régions ont ajouté une cote de priorité à leur ensemble de solutions applicatives qui reflète l’établissement des priorités des intervenants quant aux diverses possibilités de services.

4.2.4 Exemples de besoins et de services

Les figures 9 et 10 montrent des exemples de listes de besoins des utilisateurs et des fournisseurs (extraites du document intitulé British Columbia Provincial ITS Vision & Strategic Plan, 16 novembre 2001. En général, les besoins sont établis à un niveau élevé et approprié (par ex., « possibilité de réduire et de gérer la congestion »). Cet énoncé est neutre au niveau de l’architecture.

Figure 9: Exemple d’une liste de besoins régionaux des utilisateurs

Utilisateurs	Besoins associés aux STI
Automobilistes	Accès à des renseignements opportuns et précis relatifs aux conditions routières et aux conditions de trafic (y compris des renseignements sur la météo et les chantiers de construction), ce qui permet aux automobilistes de prendre des décisions éclairées concernant leurs modes de transport, les heures de déplacement et les routes à emprunter. Sécurité accrue par la disponibilité de mises en garde destinées aux automobilistes et relatives à des situations dangereuses et non sécuritaires avant qu’ils prennent la route ou alors qu’ils sont sur la route; sécurité accrue également grâce à la détection et aux interventions rapides lors d’incidents. Possibilité de payer des services de transport connexes (comme le péage et le stationnement) à l’aide de modes de paiement intégrés qui facilitent les transactions
Usagers du transport en commun	Accès à des renseignements opportuns et précis aux usagers du transport en commun relatifs aux horaires des services, aux heures de départ et d’arrivée, aux temps de déplacement estimés et aux retards. Possibilité de payer un voyage complet à l’aide de modes de paiement intégrés qui soutiennent les correspondances intermodales entre le point de départ et le point d’arrivée des usagers. En plus, les usagers du service de transport adapté et du service de transport collectif adapté à la demande devraient avoir accès à des systèmes électroniques efficaces d’établissement des horaires.
Autres	Les usagers des aéroports, des traversiers, des ports et d’autres terminus ou gares devraient avoir accès à des renseignements opportuns et précis relatifs aux horaires, aux heures de départ et d’arrivée, aux temps de déplacement estimés et aux retards. Les usagers des aéroports, des traversiers, des ports et d’autres terminus ou gares devraient avoir accès à des systèmes de gestion du transport « côté ville » efficaces (autant pour l’accès que pour l’évacuation) combinés à des systèmes intégrés de paiement du stationnement et de la billetterie, ainsi qu’à des systèmes de signalisation ou d’information sur la localisation. Les usagers de modes de transport non motorisés devraient avoir accès à des systèmes de renseignements aux voyageurs et d’information sur la localisation qui facilitent leurs déplacements et qui permettent l’intégration de la sécurité, lorsque ces modes de transport interagissent avec d’autres.

Figure 10: Exemple d’une liste de besoins régionaux des fournisseurs

Fournisseur	Besoins associés aux STI
Opérateurs de véhicules de transport en commun	Possibilité de surveiller et de gérer les opérations de transport en commun pour améliorer leur accessibilité et leur fiabilité et la sécurité des opérateurs et des passagers. Possibilité d’améliorer les services en recueillant et en analysant des données relatives à l’utilité et au rendement du système.
Opérateurs de véhicules commerciaux et exploitants de parcs routiers	Possibilité de surveiller et de gérer les opérations de transport en commun pour accroître la satisfaction de la clientèle, tout en demeurant compétitif. Accès facile à des renseignements opportuns et fiables sur l’administration, sur la délivrance de titres et de certificats, ainsi que sur le dédouanement des véhicules et des marchandises.
Exploitants de terminaux	Possibilité d’améliorer la gestion du transport terrestre grâce à la surveillance des opérations d’accès, d’évacuation et de stationnement. Possibilité d’améliorer l’efficience de l’exploitation des terminaux grâce au traitement des transactions électroniques et des paiements à l’aide d’outils intégrés.
Propriétaires ou exploitants de routes et d’autoroutes et autres autorités de transport	Possibilité d’optimiser l’utilisation de la capacité disponible. Possibilité de rétablir la capacité en détectant les incidents et en intervenant rapidement. Possibilité de réduire et de gérer la congestion. Possibilité de minimiser la fréquence et la gravité des accidents. Possibilité de donner la priorité aux services d’urgence et aux véhicules à occupation multiple (VOM) sans nuire au rendement global. Possibilité de mettre en application des règlements sans nuire à l’efficacité du système de transport. Possibilité d’exploiter et de maintenir des systèmes ou des services grâce à de l’information d’état opportune et précise. Possibilité d’intégrer des systèmes dans de nombreux ressorts territoriaux. Possibilité de réglementer efficacement et de manière sécuritaire les véhicules et l’infrastructure.

Le plan de la Colombie-Britannique a également mentionné des initiatives pour répondre à ses besoins documentés, comme le montre la Figure 11 ci-dessous.

Figure 11: Initiatives visant à répondre aux besoins de transport établis en Colombie-Britannique

Initiative	Brève description
Initiative 1 : Gestion régionale de la circulation	Le but de cette initiative est de déployer un programme intégré de gestion régionale des artères, des routes et des autoroutes dans le Lower Mainland et dans d’autres centres urbains importants, en mettant en oeuvre des stratégies régionales de gestion de la circulation de manière coordonnée et intégrée.
Initiative 2 : Applications régionales de la gestion de la demande en transport (GDT)	Le but de cette initiative est de mettre en place des services qui aideront à améliorer la gestion de la demande en transport (GDT) en milieu urbain. Puisque l’amélioration de la GDT est un but permanent du système de transport, beaucoup d’autres initiatives STI soutiennent indirectement des stratégies de GDT, comme la gestion de la circulation grâce à la régulation d’accès autoroutiers, à l’amélioration du transport en commun, etc.
Initiative 3 : Gestion du transport terrestre aux terminaux	Le but de cette initiative est de gérer la circulation (véhicules et piétons) aux principaux terminaux, comme les aéroports, les ports, les gares ferroviaires et les gares maritimes. En ce sens, la gestion du transport couvrira les véhicules entrants et sortants, des haltes routières, la gestion de la circulation sur place, la gestion du stationnement, la gestion des piétons, l’intégration des modes de paiement des services et l’intégration du transport terrestre avec les systèmes d’information des terminaux.
Initiative 4 : Gestion de la circulation dans les petites localités et dans les zones urbaines	Le but de cette initiative est de gérer la circulation (véhicules de tourisme, véhicules commerciaux et piétons) dans le contexte particulier des petites localités isolées qui ne forment pas une grande région métropolitaine.
Initiative 5 : Gestion des incidents routiers en milieu rural	Un trait caractéristique des systèmes routiers en milieu rural est qu’ils ont peu de voyageurs par kilomètre, de longues distances, des conditions routières et météorologiques défavorables, peu d’aides à la navigation et de vastes zones géographiques qui ne permettent pas la détection rapide des incidents et les interventions d’urgence. De plus, les routes rurales ont des taux de mortalité extrêmement élevés. Environ 60 % des décès sur la route et 55 % des décès dans les zones d’activité surviennent en milieu rural.
Initiative 6 : Renseignements régionaux aux voyageurs	Le but de cette initiative est de recueillir, de traiter et d’intégrer des renseignements régionaux aux voyageurs provenant de divers organismes et de les diffuser au public en temps réel. Cette information portera sur les conditions, les horaires, les retards, etc. pour tous les modes de transport (routes, transport en commun, par avion, par train, par traversier, aux passages frontaliers, etc.). Les données seront diffusées sur Internet, dans divers médias, dans des radios qui diffusent des renseignements sur l’état des routes, sur des panneaux électroniques et dans des kiosques d’information.
Initiative 7 : Renseignements aux voyageurs en milieu rural	Le but de cette initiative est de recueillir, de traiter et de diffuser des renseignements aux voyageurs en milieu rural dans toute la Colombie-Britannique. Cette information diffusée de diverses façons incluront tous les modes de transport et se concentreront sur les éléments suivants : sécurité routière; services aux voyageurs; accidents et catastrophes; guidage de parcours; détournements et détours; zones d’activité et chantiers de construction; conditions météorologiques et routières; biens et services dans les communautés rurales.
Initiative 8 : Transport urbain	Le but de cette initiative est de déployer des systèmes qui améliorent la planification, l’établissement des horaires, l’exploitation, l’entretien et la sécurité des systèmes de transport en commun. Les fonctions pourraient inclure la gestion du parc de véhicules, y compris l’intégration des communications avec les véhicules, la surveillance des véhicules, leurs emplacements et les horaires, le comptage automatique des passagers, la répartition en temps réel, et la surveillance de la sécurité à bord des véhicules. Ces fonctions peuvent être intégrées à d’autres initiatives relatives aux systèmes de paiement électronique, à l’information sur le transport en commun et aux priorités du transport en commun.
Initiative 9 : Information sur les systèmes de transport en commun	Le but de cette initiative est de déployer, de recueillir, de gérer et de diffuser des renseignements sur le transport en commun à l’aide de divers moyens. Les applications peuvent inclure des systèmes de planification des itinéraires, qui permettent aux passagers de planifier des voyages, du point de départ au point d’arrivée, en utilisant un ou plusieurs services de transport en commun et des renseignements sur les itinéraires, les horaires et les correspondances intermodales. Les applications peuvent aussi inclure des systèmes d’information en temps réel qui fournissent aux usagers des renseignements mis à jour sur les heures d’arrivée, les retards, les interruptions de service et les détournements au moyen de systèmes d’affichage dans les véhicules, en bordure des voies de circulation ou dans les terminaux, ou encore au moyen de systèmes de messages téléphoniques automatisés, de la câblodistribution ou de sites Web.
Initiative 10 : Perception électronique de péage	Le but de cette initiative est de s’assurer que la province est prête à incorporer les stratégies de perception électronique de péage (PEP), si une décision est prise d’installer un péage à une nouvelle installation ou à une installation existante. Les applications de PEP peuvent inclure une approche selon laquelle deux voies de PEP sont adjacentes ou près d’un poste de péage qui accepte également de l’argent comptant, ainsi que des systèmes complets de PEP qui ne sont pas liés à un poste de péage.
Initiative 11 : Carte à puce à applications multiples	Le but de cette initiative est de déployer une carte à puce à applications multiples pour le paiement et d’autres fonctions. Les fonctions de paiement pourraient inclure le paiement des droits de passage du transport collectif, du péage, du stationnement et des services « pages jaunes » tarifés de renseignements aux voyageurs. Parmi les autres fonctions, soulignons l’accès à certains services gouvernementaux, l’accès à des services personnalisés de renseignements aux voyageurs, des fonctions d’identification à l’appui d’autres services STI et le transfert électronique des prestations. Ce déploiement pourrait être combiné à des applications du secteur privé (par ex., achats au détail, identification, etc.).
Initiative 12 : Collecte, diffusion et partage d’information sur la conformité et la sécurité des véhicules commerciaux	Le but de cette initiative est d’élaborer un programme visant à faciliter la collecte en temps réel, la diffusion et le partage d’information sur la conformité et la sécurité des véhicules commerciaux aux niveaux provincial, national et international. Ces efforts seront axés sur l’information relative à la sécurité et à la conformité des véhicules, des conducteurs et des cargaisons dangereuses. Cela permettra d’améliorer la saisie des données relatives à l’inspection des véhicules aux postes de pesée routière ou des installations d’inspection, ainsi que d’automatiser les titres de compétence ou les autorisations des transporteurs.
Initiative 13 : Filtrage électronique routier	Le but de cette initiative est de déployer une technologie de filtrage électronique routier à des endroits stratégiques dans la province (par ex., volume élevé de circulation, points d’entrée, etc.). Des dispositifs d’identification automatisée des véhicules (AVI), combinés au pesage dynamique des poids lourds (WIM), faciliteront l’atteinte des niveaux de conformité grâce à la capacité de cibler les efforts d’application de la loi dans le cas des véhicules à risques élevés et d’accroître la productivité globale aux postes de pesée routière. On s’attend à ce que les coûts d’exploitation des transporteurs diminuent en raison de la réduction des retards.
Initiative 14 : Amélioration du dédouanement aux frontières pour les cargaisons et les véhicules	Le but de cette initiative est d’élargir le projet International Mobility and Trade Corridor (IMTC) visant à incorporer un système de traçage et de précontrôle des conducteurs, des cargaisons et des véhicules pour le dédouanement aux points de passage terrestre entre la Colombie-Britannique et l’État de Washington. Il s’agit d’une application d’un système de précontrôle électronique et de dédouanement ayant pour but d’accroître l’efficacité du transport à des postes frontaliers internationaux, ce qui permet une interface avec des fonctions douanières.
Initiative 15 : Gestion du transport intermodal des marchandises	Le but de cette initiative est de déployer une capacité de suivre à la trace et de surveiller des cargaisons de fret intermodal partout dans le système de transport. Des renseignements seront transmis aux clients, aux gestionnaires de parcs de véhicules et aux fournisseurs de services logistiques afin d’améliorer la livraison des cargaisons. Le système permettra de surveiller les conteneurs et leurs marchandises durant toute la période de leur cueillette, de leur transport et de leur livraison.
Initiative 16 : Gestion des urgences régionales	Le but de cette initiative est de déployer et d’intégrer des services régionaux de gestion des urgences afin d’améliorer la détection des urgences et des catastrophes (tremblements de terre, inondations, déversements de matières dangereuses, etc.), ainsi que la coordination et la répartition des interventions requises.
Initiative 17 : Intervention en cas d’incident mettant en cause des marchandises dangereuses	Le but de cette initiative est de déployer un programme visant à surveiller la circulation des marchandises dangereuses dans l’ensemble du réseau de transport régional (routier, ferroviaire et maritime) et à intervenir lors des incidents.
Initiative 18 : Entreposage de données	Le but de cette initiative est d’élaborer un programme de gestion des données régionales visant à soutenir la cueillette, le traitement, l’entreposage et l’extraction des données, de même que l’accès à ces données. L’initiative établira également une base centrale de données provinciales sur les accidents provenant des services policiers, des autorités routières et des organismes municipaux. Cette initiative inclura l’élaboration de normes et d’interfaces qui seront disponibles à de nombreux organismes et aux divers paliers de gouvernement.
Initiative 19 : Plan de télécommunications	L’infrastructure de communication est l’épine dorsale de tout réseau régional des STI. La majorité des autres initiatives ont des exigences en matière de communication, y compris la communication « centre à centre » (c.-à-d. entre les centres de gestion du trafic) et la communication entre les centres de gestion du trafic et les dispositifs sur le terrain. Cette initiative devrait permettre d’élaborer un plan global des communications STI.
Initiative 20 : Architectures régionales des STI	L’architecture des STI pour le Canada définit à la fois la fonctionnalité (processus et flux de données) et les entités physiques (ensembles de produits et sous-systèmes) requises pour soutenir un déploiement de STI à un niveau élevé et de manière générique. Le but de cette initiative est de définir les mêmes composants (fonctionnels et physiques) au niveau régional pour les initiatives assignées à chaque région.
Initiative 21 : Étude de marché sur les STI	Cette initiative impliquerait l’élaboration d’une étude de marché sur les STI régionaux visant à examiner les possibilités de partenariats avec des sociétés du secteur privé et d’autres organismes concernés par le partage d’information, de ressources ou d’infrastructures de communication découlant de divers déploiements de STI dans la région. Le but de l’initiative est de déterminer les possibilités de partager les coûts de conception, de construction, d’exploitation et d’entretien de toutes les composantes du réseau.
Initiative 22 : Diffusion à l’interne et è l’externe	Cette initiative inclut l’élaboration d’un programme d’intégration des STI visant à fournir une sensibilisation à l’égard des applications STI et une diffusion, à l’interne et à l’externe. Afin d’obtenir le financement futur et le soutien gouvernemental, il est essentiel d’obtenir le soutien du public aux STI en tant que solutions à l’augmentation de la demande de trafic. Il est aussi important de sensibiliser les planificateurs, les responsables de la mise en oeuvre et les décideurs à l’égard des avantages des STI, en particulier pour assurer la mise en oeuvre des STI la plus efficace et la plus efficiente possible.
Initiative 23 : Centre de gestion intégrée de la circulation	Présentement, des organismes régionaux exploitent et entretiennent des centres de gestion du trafic (CGT) ou des centres des opérations, y compris des CGT du ministère des Transports pour certains tronçons d’autoroutes, TransLink, des services d’aérotrains et d’autobus, le centre de gestion du trafic de la ville de Vancouver qui coordonne l’intégration de la signalisation.

Étape 2 : Collecte des Données - Élaborer un concept d’exploitation

Objectifs

• Déterminer les rôles et les responsabilités actuels et futurs des intervenants dans la mise en oeuvre et l’exploitation des composants STI régionaux.
• Obtenir un ralliement autour de ces rôles et de ces responsabilités en jetant les bases de futures ententes interorganismes.

Processus - Principales activités

Se préparer

• Regrouper des documents qui établissent les responsabilités dans des scénarios multi-agences (par ex., des plans de gestion des incidents)

Élaborer un concept d’exploitation

• Renforcer l’inventaire des STI en repérant chaque organisme, compagnie ou institution qui met en oeuvre, exploite et entretient chaque composant de l’inventaire qui soutiendra les interfaces interorganisationnelles, privées ou publiques (au besoin, allonger la liste des intervenants)
• Élaborer divers scénarios opérationnels pertinents qui requièrent une coopération parmi un vaste bassin d’intervenants (les incidents majeurs et les événements spéciaux sont de bons scénarios qui impliquent une majorité d’intervenants)
• Organiser une réunion ou un atelier où les intervenants peuvent examiner les scénarios préparés et déterminer les rôles actuels et les possibilités d’améliorer la coopération ou l’intégration dans l’avenir
• Documenter les responsabilités actuelles et futures de chaque intervenant dans chacun des scénarios
• Recueillir des constatations clés dans un concept d’exploitation de haut niveau

Établir un consensus

• Établir un consensus sur les questions qui feront surface lors de l’élaboration du concept d’exploitation; établir et documenter les questions clés qui ne peuvent pas être résolues

Intrants - Sources d'information

• Inventaire et établissement des besoins et des services provenant de la tâche précédente
• Tout document qui établit les rôles et les responsabilités

IntrExtrant - Résultats du processus

• Documentation sur le concept d’exploitation dans la région
  • Aperçu de la manière dont les STI sont fournis
  • Rôles et responsabilités

4.3 Élaborer un concept d’exploitation

L’inventaire nomme les intervenants associés à chaque composant STI dans la région. À l’étape de l’élaboration du concept d’exploitation, les rôles et les responsabilités actuelles et futures de chaque intervenant dans l’exploitation des services régionaux sont définis plus en détail. Le concept d’exploitation documente ces rôles et ces responsabilités pour des domaines de services de transport relatifs aux besoins de la région et pour des scénarios d’exploitation facultatifs. Ce concept fournit un « résumé » de la manière dont les intervenants de la région travaillent ensemble pour fournir des services STI.

4.3.1 Processus d’élaboration du concept d’exploitation

C’est l’étape du processus où les possibilités d’intégration dans la région sont d’abord documentées, alors que l’accent est mis sur la participation des intervenants. L’objectif n’est pas de définir officiellement chaque composant STI ou les exigences particulières relatives à l’intégration. Cela sera fait plus tard. À cette étape, l’objectif est d’établir les rôles organisationnels actuels et futurs dans le système de transport régional. Comme c’est le cas des autres produits de l’architecture régionale des STI, la manière dont l’information sur le concept d’exploitation est recueillie et exprimée variera d’une région à l’autre.

Le niveau de détail inclus dans le concept d’exploitation variera également d’une région à l’autre. Certains concepts d’exploitation mettent l’accent sur une définition du rôle général de chaque intervenant dans la prestation de services de transport dans la région. Des concepts d’exploitation plus détaillés pourraient inclure une description exhaustive de la manière dont les intervenants interagiront pour fournir des services particuliers de transport dans des situations également particulières. L’examen des intervenants et l’itération sont une composante importante du processus à mesure que les concepts initiaux sont élargis et se précisent.

Le facteur peut-être le plus crucial dans le succès du processus d’élaboration du concept d’exploitation est la participation des intervenants. L’objectif ultime n’est pas de créer un tableau des rôles et des responsabilités, mais plutôt de permettre aux intervenants de faire des suggestions et d’adhérer aux décisions prises de manière à s’approprier le concept d’exploitation. Aux étapes subséquentes, ces rôles et ces responsabilités constitueront le fondement des ententes interorganismes.

Une des principales difficultés dans le processus d’élaboration du concept d’exploitation pour une architecture régionale des STI est la grande diversité des organisations et des systèmes en cause. Il serait presque impossible d’élaborer un seul concept d’exploitation contigu pouvant couvrir « une journée dans la vie » d’un système de transport régional de surface. Une façon de pallier cette difficulté est de définir plusieurs zones de rôles et de responsabilités, chacune couvrant un aspect particulier du système de transport. Par exemple, divers concepts d’exploitation pourraient être élaborés, chacun portant sur un service STI en particulier.

Une façon d’utiliser une approche axée sur des scénarios consiste à organiser une réunion au cours de laquelle un animateur présente aux intervenants clés les événements d’un scénario préparé. À chaque étape du scénario, l’animateur travaille avec le groupe afin de déterminer :

1. quels sont les rôles et les responsabilités actuels – par exemple, le ministère provincial des Transports envoie par télécopieur des renseignements sur les fermetures de routes aux comtés, au principal centre métropolitain de la région et aux médias;
2. quels sont les problèmes – par exemple, l’information sur les fermetures de routes tendent à être très dynamiques, et de nombreux organismes qui pourraient les utiliser ne les reçoivent pas (par ex., des services médicaux d’urgence);
3. quelles sont les possibilités – par exemple, la possibilité d’améliorer la coordination des fermetures à plus long terme entre les organismes; recueillez des renseignements sur les fermetures à un endroit et rendez-les disponibles à tous les organismes exploitants et aux voyageurs.

L’animateur de la réunion doit s’attendre à ce que plus de « possibilités » soient soulevées plutôt que d’être abordées en profondeur dans le temps qui lui sera imparti. Une approche courante consiste à énumérer toutes les idées et à en choisir quelques-unes pour étoffer un concept d’exploitation. Pour reprendre l’exemple cité plus haut, l’animateur pourrait faire un suivi et déterminer qui mettrait en place et exploiterait le système d’information sur les fermetures de routes, qui seraient les clients et qui diffuserait l’information.

Un forum comme celui-ci est une bonne occasion de vérifier si les intervenants sont coopératifs et prêts à faire face aux changements qui surviendraient, si les concepts d’exploitation étaient mis en oeuvre. Un certain nombre de problèmes, la plupart non techniques, surgiront durant le processus d’élaboration d’un concept d’exploitation. Autant que possible, ces problèmes devraient être documentés et résolus. Il existe de nombreuses stratégies efficaces de résolution de problèmes, dont le choix d’un animateur qui n’a pas un intérêt direct dans le ou les problèmes et qui peut aider vraiment les intervenants à trouver une solution gagnant-gagnant.

Considérations relatives à la sécurité

4.3.2 Outils et ressources

4.3.3 Concept d’exploitation (extrant)

Le concept d’exploitation pour une architecture régionale des STI établit les rôles et les responsabilités opérationnels.

Rôles et responsabilités opérationnels

Une façon efficace d’organiser les rôles et les responsabilités opérationnels est d’utiliser les services STI, soit les services aux utilisateurs, soit les ensembles de solutions applicatives, pour structurer l’extrant. Pour chaque service STI, le concept d’exploitation présente un aperçu général de la manière dont le service sera fourni dans la région et des rôles et des responsabilités de chaque intervenant dans la prestation de ce service. En outre, les principaux domaines de coordination entre les intervenants peuvent être documentés. Cet aperçu est fort utile parce qu’il soutiendra les définitions des interfaces et les ententes institutionnelles qui seront conclues aux étapes subséquentes.

Quand vient le temps de documenter les rôles et les responsabilités de chaque service STI, il importe de garder à l’esprit que tout service STI peut être mis en place de différentes façons. Par exemple, un système de signalisation assurant la priorité des véhicules d’urgence peut être mis en place au moins de deux manières :

• Un véhicule d’urgence peut signaler directement la priorité en utilisant l’équipement dont il dispose, notamment aux intersections.
• Subsidiairement, le centre de répartition associé au véhicule d’urgence peut communiquer avec le centre de gestion du trafic qui contrôle la signalisation et demander qu’une priorité soit accordée au véhicule. Le centre de gestion du trafic peut alors signaler la priorité à distance.

Quoique la première solution ait cours depuis plus longtemps, la seconde pourrait être intéressante pour les régions qui ont déjà mis en place des dispositifs d’identification automatisée des véhicules (AVI) dans leurs véhicules d’urgence et un système de signalisation à boucle fermée. Le concept d’exploitation devrait explorer d’autres solutions de rechange, comme dans cet exemple, et documenter les choix pour la région. Par exemple, un concept d’exploitation pour un système de signalisation assurant la priorité des véhicules d’urgence pourrait choisir la première solution, puis établir les rôles et les responsabilités des organismes de sécurité publique et de gestion de la circulation concernés. Lorsque le choix d’un organisme ne peut pas être fait, d’autres concepts de remplacement peuvent être retenus aux fins d’une analyse future.

Rôles et responsabilités dans la mise en oeuvre

Ce volet du concept d’exploitation inclut l’établissement clair des responsabilités de chaque intervenant dans la région à l’égard de sa mise en oeuvre et de son entretien.

Des renseignements plus détaillés peuvent être fournis lorsque les composants STI sont partagés et que les axes de responsabilité sont plus compliqués. Par exemple, les rôles et les responsabilités pourraient être documentés dans une matrice d’affectation des responsabilités montrant des ressources partagées sur un axe et les intervenants sur l’autre axe. Chaque cellule indiquerait la responsabilité de chaque intervenant à l’égard de cette ressource partagée.

4.3.4 Exemples de concepts d’exploitation

Les concepts d’exploitation peuvent être documentés sous différents formats, comme des descriptions textuelles, des tableaux et des graphiques. Chaque région aurait avantage à examiner ces exemples et à établir une approche susceptible de répondre le mieux à ses besoins.

Exemple 1 : Rôles et responsabilités représentés dans un tableau

Une liste partielle des rôles et des responsabilités des intervenants dans l’Architecture des flux d’information frontaliers (AFIF) est illustrée au Tableau 3. Cette liste documente les rôles et les responsabilités associés à l’ensemble de solutions applicatives « Paiement électronique ».

Exemple 2 : Rôles et responsabilités représentés à l’aide de Turbo Architecture

Les rôles et les responsabilités des intervenants dans l’AFIF ont été élaborés à l’aide de Turbo Architecture. La Figure 12 montre l’onglet « Ops Concept » du logiciel, où les zones de rôles et des responsabilités sont étendues. Un intervenant, l’Agence des services frontaliers du Canada, a été sélectionné dans une zone de rôles et de responsabilités (Systèmes d’inspection aux frontières). Comme l’indique le côté droit de la figure, l’analyste a rédigé sept énoncés de rôles et de responsabilités pour l’ASFC dans cette zone de rôles et de responsabilités.

Tableau 3: Rôles et responsabilités dans l’Architecture des flux d’information frontaliers

Service de transport	Intervenant	Intervenant
Gestion des incidents	Exploitants de ponts ou de tunnels	Fournir des renseignements au système de rapprochement du péage afin de coordonner les paiements et l’échange d’information avec d’autres centres de service de péage. Interrompre le paiement du péage durant les événements extrêmes, comme des désastres naturels et des évacuations de groupes de personnes, au besoin. Gérer le processus de collecte de péage électronique; détecter et traiter les infractions des automobilistes qui traversent un poste de péage sans payer.
	Institutions financières	Rapprocher les paiements de péage électronique avec les autorités responsables du péage et les exploitants de ponts ou de tunnels.
	Autorités responsables du péage	Échanger des renseignements sur les horaires de péage, les clients et d’autres services de péage afin de coordonner les opérations de péage. Gérer les ententes de réciprocité entre les autorités responsables du péage et les centres de services en échangeant des renseignements qui soutiennent le rapprochement des frais de péage payés par les clients qui sont inscrits auprès d’autres centres de services de péage. Interrompre le paiement du péage durant les événements extrêmes, comme des désastres naturels et des évacuations de groupes de personnes, au besoin.

Étape 2 : Collecte des Données - Définir les exigences fonctionnelles

Objectifs

• Élaborer une description de haut niveau de la fonctionnalité requise par chaque composant STI dans l’inventaire

Processus - Principales activités

• Déterminer le niveau des exigences fonctionnelles appropriées à la région
• Établir les composants STI qui requièrent une définition des exigences fonctionnelles. Les composants inclus dans un inventaire qui sont à la périphérie des STI (par ex., les institutions financières) n’ont pas à être définis au niveau de la fonctionnalité, puisqu’ils ne sont pas liés à l’architecture régionale des STI.
• Renforcer les choix de services STI et le concept d’exploitation pour définir les exigences fonctionnelles en mettant l’accent sur ceux qui ont des répercussions régionales
• Utiliser l’architecture des STI pour le Canada (sous-systèmes, ensembles de solutions applicatives, ensembles de produits et exigences fonctionnelles), au besoin, afin de soutenir l’élaboration des exigences fonctionnelles
• À l’aide des renseignements recueillis aux étapes précédentes, documenter les fonctions requises pour soutenir les services que les intervenants souhaitent fournir dans la région

Établir un consensus

• Les intervenants devraient participer à l’élaboration des exigences fonctionnelles pour que les fonctions soient définies avec précision et pour qu’ils puissent soutenir les exigences qui seront imposées à leurs composants STI.

Intrants - Sources d'information

• Inventaire, services STI et concept d’exploitation établis aux étapes précédentes
• Échanges d’information définis aux étapes suivantes, si des exigences fonctionnelles plus détaillées doivent être définies

IntExtrant - Résultats du processus

• Exigences fonctionnelles documentées pour chaque composant STI inclus dans l’inventaire

4.4 Définir les exigences fonctionnelles

À cette étape, les tâches ou les activités (« les fonctions ») accomplies par chaque composant STI dans la région sont définies, documentant ainsi la partie du travail exécuté par chaque composant pour fournir un ou des services STI. Rappelez-vous que les composants STI peuvent être associés à un ou plusieurs sous-systèmes ou terminateurs de l’architecture des STI pour le Canada. Les exigences fonctionnelles sont associées aux composants STI, eux-mêmes associés à un ou plusieurs sous-systèmes. Les terminateurs n’ont pas d’exigences fonctionnelles dans une architecture régionale des STI. Quand nous faisons référence aux composants STI dans la présente section, nous faisons explicitement référence aux composants STI associés à un ou plusieurs sous-systèmes de l’architecture des STI pour le Canada.

4.4.1 Processus d’élaboration des exigences fonctionnelles

Avant de rédiger la première exigence fonctionnelle, déterminez le niveau de détail approprié des exigences fonctionnelles. Le niveau de détail est établi pour chaque architecture régionale des STI à partir des besoins de la région. À vous de choisir!

Bien que certaines régions aient des objectifs uniques qui exigent des spécifications plus détaillées, des spécifications très détaillées sur les exigences fonctionnelles dans une architecture régionale des STI peuvent être contreproductives, car elles augmenteront le travail d’élaboration et d’entretien de l’architecture régionale des STI. En fait, elles ne sont pas vraiment requises jusqu’au moment de définir les projets. À moins que votre région ait des caractéristiques particulières, maintenez les spécifications relatives aux exigences fonctionnelles à un niveau élevé dans l’architecture régionale des STI et laissez les spécialistes de ce champ d’applications particulier élaborer des spécifications plus détaillées, quand le temps viendra de concevoir et de mettre en oeuvre des projets.

En général, les exigences fonctionnelles devraient être faciles à rédiger parce qu’elles devraient découler directement des décisions prises au sujet des services STI, du concept d’exploitation et des choix d’interfaces faits aux autres étapes du processus. Si de nombreuses décisions arbitraires sont nécessaires pour parfaire les exigences fonctionnelles, cela pourrait vouloir dire que les exigences sont trop détaillées.

Pour commencer au bon niveau de détail, pensez d’abord à la motivation requise pour rédiger les exigences fonctionnelles. Vous tentez de préciser les choses qu’un composant STI doit faire pour « réaliser sa part de l’accord » dans une architecture régionale des STI. Même si elle est de niveau élevé, la spécification doit être achevée, c’est-à-dire qu’elle doit énumérer tout ce que le composant STI doit faire. Cependant, elle ne devrait pas énumérer les choses que le composant STI n’est pas tenu de faire.

Prenons un exemple : des intervenants ont décidé que le centre de gestion du trafic du ministère provincial des Transports rendrait disponibles les images des caméras de télévision en circuit fermé à divers utilisateurs professionnels dans la région. Une spécification de niveau extrêmement élevé pour ce centre de gestion du trafic pourrait stipuler que le centre « gère la circulation ». De toute évidence, cette exigence fonctionnelle est trop vague, parce qu’elle ne dit pas que le ministère provincial des Transports doit partager les images des caméras de télévision en circuit fermé et parce qu’il pourrait être implicite que le ministère doive exécuter des fonctions de gestion de la circulation qui n’ont jamais été voulues. Par ailleurs, une spécification pourrait aller trop loin en établissant des exigences relatives au rendement du composant STI ou à une technologie particulière. Les exigences fonctionnelles doivent seulement préciser CE que le composant STI doit faire. Elles ne doivent pas préciser le niveau de rendement requis du composant STI ou la manière dont il fera ce qu’il doit faire. Un ensemble approprié d’exigences fonctionnelles dans cet exemple pourrait être le suivant :

• Le centre de gestion du trafic du ministère provincial des Transports rendra disponibles les images des caméras de télévision en circuit fermé aux utilisateurs professionnels et aux médias.
• Le centre de gestion du trafic du ministère fournira la capacité de désactiver les images des caméras de télévision en circuit fermé de manière sélective, empêchant ainsi leur distribution aux médias dans des circonstances particulières.
• Le centre de gestion du trafic du ministère fournira aux utilisateurs professionnels, de manière sélective, un accès au contrôle des caméras (fonctions de pivotement horizontal, d’inclinaison verticale et de zoom).

Les exigences fonctionnelles n’ont pas à être rédigées pour chaque composant inclus dans l’inventaire. Comme nous l’avons vu à la section 4.1, un inventaire inclut normalement des composants à la périphérie des STI qui ne fournissent pas directement des services de transport, mais qui échangent des renseignements avec les composants STI. L’exemple classique d’un composant inclus dans un inventaire qui est à la périphérie des STI est une institution financière qui fait interface avec des composants STI qui soutiennent des transactions financières. En général, une architecture régionale des STI devrait inclure des fonctions pour des composants STI et ne devrait pas inclure des fonctions pour les composants de l’inventaire à la périphérie des STI.

Une limite architecturale doit être établie afin de déterminer là où des exigences fonctionnelles sont requises. Il existe diverses façons d’établir cette limite.

1. La meilleure approche consiste à déterminer si chaque composant STI inclus dans l’inventaire sera mis en oeuvre ou mis en valeur grâce à la mise en oeuvre de projets de STI par les intervenants de la région. Les composants STI qui sont mis en oeuvre ou mis en valeur grâce à la mise en oeuvre de projets de STI se situent dans la limite des STI et devraient inclure des exigences fonctionnelles. Ce pourrait être le critère le plus déterminant quant à la limite d’une architecture régionale des STI, puisque cela reflète l’une des meilleures utilisations des exigences fonctionnelles – qui sont un point de départ pour la spécification des projets de STI.
2. Le composant STI est-il dans cette région ou dans une autre région sujette aux exigences d’une autre architecture régionale des STI? Les composants STI dans les autres régions ne devraient pas être spécifiés au niveau de la fonctionnalité.
3. Tenez compte des services fournis par chaque composant STI. Si le composant STI fournit des services liés au transport de surface, il se situe probablement à l’intérieur de la limite architecturale et devrait être soutenu par des exigences fonctionnelles.
4. Examinez la correspondance du composant STI avec l’architecture des STI pour le Canada. Les composants STI qui ont une correspondance seulement avec les terminateurs de l’architecture des STI pour le Canada pourraient être à la périphérie des STI, alors que les composants STI qui ont une correspondance avec les sous-systèmes de l’architecture des STI pour le Canada pourraient se situer dans la limite architecturale et inclure des exigences fonctionnelles. Cette approche fonctionne aussi longtemps que la limite de l’architecture régionale des STI coïncide exactement avec la limite de l’architecture des STI pour le Canada, mais ce n’est pas toujours le cas. Il convient d’appliquer cette règle seulement en conjugaison avec les critères susmentionnés.

Considérations relatives à la sécurité

4.4.2 Outils et ressources

L’architecture des STI pour le Canada constitue une bonne source pour les exigences fonctionnelles qui pourraient être utilisées de manière sélective dans une architecture régionale des STI. L’architecture physique inclut des descriptions générales des sous-systèmes qui fournissent un aperçu global de ce que les composants STI font. Au niveau de détail suivant, les ensembles de produits incluent des descriptions plus précises de la fonctionnalité requise pour chaque service soutenu par un sous-système. Chaque ensemble de produits contient également un ensemble d’exigences fonctionnelles qui peuvent être adoptées telles quelles ou modifiées pour répondre aux besoins particuliers de la région. Tous les niveaux de descriptions sont liés à l’architecture d’un hypertexte sur le site Web et le cédérom, ce qui permet une navigation facile entre les niveaux de détail. L’architecture des STI pour le Canada est disponible à l’adresse http://www.tc.gc.ca/innovation/sti/fra/architecture.htm.

4.4.3 Exigences fonctionnelles (extrant)

Les exigences fonctionnelles textuelles de niveau élevé peuvent être préparées afin de décrire CE que chaque composant STI fait pour soutenir les services STI qui ont été sélectionnés dans la région. Les exigences fonctionnelles sont des énoncés qui définissent chaque fonction importante exécutée par un composant STI, en mettant l’accent sur les fonctions qui ont des répercussions régionales.

4.4.4 Exemple d’exigences fonctionnelles

Cette section présente un exemple d’exigences fonctionnelles à partir de l’utilisation de Turbo Architecture.

La Figure 13 montre l’onglet « Requirements » dans Turbo Architecture à l’aide de l’Architecture des flux d’information frontaliers (AFIF). Ici, les secteurs fonctionnels ont été automatiquement sélectionnés à partir des ensembles de solutions applicatives, et des composants STI ont été sélectionnés pour certains de ces secteurs fonctionnels. Dans cet exemple, le secteur fonctionnel de la surveillance de la circulation a comme composant STI sélectionné le Canadian Municipal Traffic Operations Centre. En mettant en surbrillance le composant et en choisissant le bouton « Requirements », on obtient l’écran illustré à la Figure 14, où l’analyste peut sélectionner le menu des exigences fonctionnelles connexes. Dans cet exemple, l’analyste a choisi sept des huit exigences fonctionnelles possibles.

---

 

 

[ Précédente : Chapitre 3 ]

[ Suivante : Chapitre 5 ]