retour d'expérience tiré de létude de définition d'un segment sol dobservation de la...

Retour d'expérience tiré de l’étude de définition d'un

Segment Sol d‘Observation de la Terre

Rose-MarieBillot

10ème Journée Thématique AFIS

RafaelEstanguet

14 décembre 2010 - Toulouse

2

Contenu de la présentation

Contexte de l’étude

Enjeux & Problématiques

Démarche méthodologique et outil d’ingénierie mis en œuvre

Bilan de l’étude

3


Etude d’architecture d’un sous-ensemble du segment sol d’un programme d’observation de la Terre

CENTRES UTILISATEURS- Gestion des demandes de prise de vue

- Réception des données et traitement des images

CNES : commande et suivi du satellite

Programmation des prises de vue

CNES : expertise et qualité image

Plu

sieu

rs p

art

enair

es

CNES :Plate-forme de test

4

Lanceur et Segment spatial

Segment sol spatialSegment sol spatial Segment sol utilisateurSegment sol utilisateur

P R O G R A M M E

Commande/Contrôle

SimulateurSatellite

StationTM/TC

Mécaniquespatiale

Calibration

SimulateurMission

MissionPlanning

StationRéception

Simulateur(valise) TMI

IngestionInventaire

CatalogueArchive

ProductionLivraison

Requêtesutilisateur

ExploitationImagerie

LogicielBord

Sécurité, SdF, Supervision, Administration, Communication et Support

Architecture Système Développement AIVQ Opération/MCO/SLI

PerformanceInterface

InfrastructureDéploiement

Modes et opérationsSécurité

SdFEnvironnement

Moyens et produitsMaintenance et SLI

ErgonomieFacteurs humains

Transport et stockageDocumentation

PhysiqueConception et

réalisationRéserve et extension

Mise en serviceRetrait de service

Coûts et délaisQualité

RéglementationMoyens de

validation/qualification…

ContraintContrainteses

Un système complexeEtude d’architecture d’un segment sol spatial

d’observation de la terre en phase A

SimulateurStation

Services utilisateursServices utilisateurs

FonctionsFonctions

5


L’étude a été menée par une équipe CNES regroupant différentes parties prenantes (équipe système, experts commande/contrôle du satellite, programmation des prises de vue, traitement et qualité image)

Le CNES a demandé à CS un support méthodologique et un support de rédaction et mise en forme de tout le dossier résultat de l’étude

L’équipe CS avait des expériences de réalisation de segments sol de mission d’observation de la Terre

Mode de fonctionnement : Réunion hebdomadaire CNES/CS (30 réunions en tout) pour pouvoir côté CNES

piloter finement le travail technique et faire tous les choix structurants

Entre les réunions traitement des actions décidées en réunion par les deux parties

Échange CNES/partenaire sur l’avancement et les hypothèses de travail

Durée de l’étude : 6 mois

6





Bilan de l’étude

7

Enjeux & Problématiques (1/3)

Mission du système : satisfaire des demandes de produit image

Un grand nombre d’éléments en interface

De nombreuses interactions

Une forte dynamique externe

Un périmètre fonctionnel à affiner

Le segment soldans son

environnement

8


Référentiel d’exigences non homogène, incomplet, et très versatile (fréquence hebdomadaire des évolutions)

Centres CNES

Segment Sol d’Observation de la Terre

Centresutilisateurs

SpécificationTechnique(systèmed’intérêt) Document

d’exigencesfonctionnelles(sur-système) Compléter et mettre en

cohérence les exigences techniques

Maintenir un référentiel d’exigences

9


Une équipe pluridisciplinaire à faire collaborer Architectes chaîne mission/programmation

Architectes chaîne image

Architecte chaîne commande/contrôle

Architecte système (programme et sol)

Architecte sécurité

…

Adopter un langage commun : partager la sémantique des objets d’ingénierie manipulés

Obtenir l’adhésion à la démarche d’ingénierie proposée, aux formalismes de modélisation et à l’outil retenu

10





La démarche et l’outil

Le référentiel d’exigences techniques

La conception fonctionnelle

Le raisonnement collaboratif sur les modèles

Bilan de l’étude

11

Définition de la démarche d’ingénierieet choix d’un outil adapté

Démarche ajustée à partir du référentiel d’ingénierie système de CS (référentiel basé sur l’ISO 15288 et l’INCOSE SE Handbook)

Besoin Produi

t Image

Solution optimisée

Supportée par l’atelier de génie système MDWorkbench For Defence

Démarche d’ingénierie système

12

Modèle duContexteFonctionnel

Modèle d’unScénarioOpérationnel

Etablir le référentiel d’exigences techniques

SpécificationTechnique(systèmed’intérêt)

Documentd’exigences

fonctionnelles(sur-système)

CR réunions

techniques

Homogénéisation, résolution des conflits,incohérences, imprécisions…

Documentsdisponiblesen entrée

Référentield’exigencestechniques

-Vue opérationnelle-Vue fonctionnelle-Vue performances-Vue interfaces-Vue contraintes

Spécification

TechniqueUnifiée

13

Conception de l’architecture fonctionnelle

Analyse mission & définition du concept

opérationnel (hors scope)

Définition d’une architecture fonctionnelle qui supporte le concept opérationnel

Evaluation,Optimisation & Vérification dufonctionnementRéception

Demande AcquisitionImage

disponible

délai acquisitionâge information

délai d’accès

Validation dufonctionnement

14

Vérification de la cohérence des interfaces fonctionnelles & physiques entre les constituants réalisée « à la main » (vues « table »):

Conception organique

Répartition des fonctions dirigée par l’organisation « Cnes & partenaires »

Répartition géographique des centres non étudiée

15

Con

cep

tion

Org

an

iqu

eC

on

cep

tion

Fon

cti

on

nelle

Travail collaboratif et processus itératifs

Des raisonnements objectifs qui s’appuient sur des modèles sémantiques, fonctionnels, dynamiques, organiques… à chaque étape de la conception

Sp

écifi

cati

on

Tech

niq

ue

Requirement

R1 R2

R1.1 R1.2

Fonction&Flux

Constituant&Lien

16





Bilan de l’étude

17

Bilan de l’étude : point de vue de CS

Niveau de détail : ne pas aller trop loin dans la décomposition fonctionnelle (juste nécessaire)

Un référentiel constitué par un modèle cohérent & complet

Quelques lacunes de l’outil pour conserver la cohérence/complétude des I/F

Un effort important sur la conception fonctionnelle (intérêt des scénarios eFFBD)

Le modèle en chiffres : Plus de 200 fonctions

Plus de 300 flux

Une vingtaine de scénarios de fonctionnement

Une centaine de constituants répartis sur 3 niveaux de décomposition

La documentation en chiffres : ST : 170 pages

NT : 33 pages

DA : 94 pages

Annexe DA : 275 pages (vue tables & matrices)

DJ : 40 pages

18

Bilan de l’étude : point de vue du CNES

En sortie de l’étude le Cnes dispose d’un Modèle d’architecture et d’une documentation structurée et justifiée entièrement issue du modèle

Le Cnes a pu prendre en main le modèle pour effectuer des modifications significatives et re-générer les documents associés. Ces documents ont été présentés en revue de définition système.

Les résultats de cette étude sont utilisés pour produire les spécifications des sous-systèmes identifiés par l’architecture organique à partir :

De la liste des fonctions/Flux portés par chaque constituant et des besoins fonctionnels auxquels ils répondent

De la projection des exigences non-fonctionnelles sur chaque constituant

Des hypothèses sur les fonctions/constituant

Des interfaces définies

19

Bilan de l’étude : point de vue du CNES

Apport indéniable de la méthodologie et de l’outil Pour fédérer les points de vue de chaque architecte et optimiser le travail

Pour vérifier l’architecture fonctionnelle

Pour consolider l’architecture organique

Le contexte du programme nous conduit à spécifier les composants logiciels avec une méthode « maison » basée sur UML et à gérer les exigences sous DOORS

Le modèle ne sera pas maintenu pendant cette phase de spécification

Le modèle apporte les éléments structurant pour réaliser cette phase

1ère sensibilisation positive sur cette méthode et cet outil …