The same story can end differently depending on what r-io suite does. RUNS keeps each playing of a scenario, from Play to the next Restart or to the end of the story, with the supervision settings it had, and sets runs side by side to see what one did that another did not.
01
A run is recorded while it plays
While a run goes on, r-iosemit reads r-io suite every two seconds, as any observer of the field could, and notes each key moment with the clock of the use case: actualities and risks that appear, change or disappear, deductions, solutions deployed and adapted, steps of the tasks, states of the assets, effects of the tasks and tracks taken at the forks. It also notes the settings of the supervision of r-iota (auto mode, extrapolation…). The recorder writes nothing in r-io suite. The run is saved in the scenario; the RUNS tab shows a red dot while one is being recorded.
02
The list of runs
Each run has an editable name, its recording date, its settings as badges, its deductions (the time each took and, with a Given deduction time, the time given and the difference), its number of moments and, when it was filmed, its video in the Scene column. The buttons are Timeline, Replay, Suggest forks (forks on what appeared during the run, to fill in what could happen instead) and Delete; Delete all deletes every saved run with its video.
03
Compare up to three runs
Tick runs in the Compare column: they become A, B and C. Their moments are drawn on aligned lanes on the time of the use case, then listed by date with a column per run; a moment only one run has is in bold, one they all have at different dates is shifted. Filter by kind of moment (Actuality, Risk, Deduction, Solution, Task, State, Fork, Task effect) or tick Differences only. View process shows the process of a solution as it was then, with what an adaptation added. How they ended and Resources impacted close the comparison.
04
A run on the timeline
Timeline draws a run under the tracks of TIMELINE: its row of expected effects from the tasks and its row of detected problems, a line per risk or actuality with its probability each time it changed. To show the run, the story is restarted first.
05
Video of a run
With Film the runs ticked above the scene, the 3D view is filmed from the first step to Restart by an automatic camera: a close-up on an asset that changes state, from behind on a person who moves, the overview otherwise, with the time and a caption on the image. The video is kept with the run on the server and can be watched or downloaded from the Scene column.
06
Replay
Replay plays a run again from the start of the story with the supervision settings it had. When they differ from the current ones, a warning lists them (setting, now, in this run): r-iosemit writes them in the project, for everyone working on it, and they stay after the replay. This is the one place where r-iosemit writes settings of r-io suite, and it asks first. The replay is recorded as a new run.
07
Use case: Barbecue
The Henri Barbecue Story of the Barbecue ships with three reference runs: without supervision Henri burns and drowns, in auto mode Julie saves him, with extrapolation Paul puts the barbecue out before Henri gets there. Compared, the extrapolation run shows the risk, the deduction, the move of Paul and the extinction between 09:01:34 and 09:02:24, where the first run has nothing.
The three reference runs with their settings, their deduction times, their moments and their videos.Without supervision (A) and with extrapolation (B): the moments of each run, in bold when only one of them has it.The warning before replaying the first run: the settings that are about to change, for everyone working on this project.
r-iosemit plays the field, not r-io suite. No r-io suite application calls it or knows that it exists: for r-io suite, every event it plays is a real one. It reads the knowledge base of r-io suite (states, positions, alerts, risks, tasks) to choose its tracks and to record its runs, without ever writing what it reads. It acts only through the channels of the field: the sensors (their datasets, planned values, GPS moves and forecasts published as a provider would), the messaging sensors, the human-task service for the simulated tasks, and the clock API of the use case once the operator opened it in r-ioga (Edit project › Use case clock › Allow remote clock control).
A few authoring items act on the knowledge space directly, and the dialogs say so: a planned risk level (like the Potentialities Management slider), a referenced actuality (a FREEZE actuality made ACTIVE, or a clone of a REFERENCE one), Previous step and Restart (they restore a checkpoint of the knowledge space kept by the server) and Replay (it writes the supervision settings of a run back, after a warning).
La même histoire peut finir autrement selon ce que fait r-io suite. RUNS garde chaque lecture d’un scénario, de Play au Restart suivant ou à la fin de l’histoire, avec les réglages de supervision qu’elle avait, et met des runs côte à côte pour voir ce que l’un a fait et l’autre non.
01
Un run s’enregistre pendant qu’il se joue
Pendant un run, r-iosemit lit r-io suite toutes les deux secondes, comme tout observateur du terrain pourrait le faire, et note chaque moment clé avec l’horloge du cas d’usage : actualités et risques qui apparaissent, changent ou disparaissent, déductions, solutions déployées et adaptées, étapes des tâches, états des biens, effets des tâches et pistes prises aux fourches. Il note aussi les réglages de supervision de r-iota (mode auto, extrapolation…). L’enregistreur n’écrit rien dans r-io suite. Le run est sauvegardé dans le scénario ; l’onglet RUNS montre un point rouge pendant un enregistrement.
02
La liste des runs
Chaque run a un nom modifiable, sa date d’enregistrement, ses réglages en badges, ses déductions (le temps de chacune et, avec un temps de déduction Given, le temps donné et l’écart), son nombre de moments et, s’il a été filmé, sa vidéo dans la colonne Scene. Les boutons sont Timeline, Replay, Suggest forks (des fourches sur ce qui est apparu pendant le run, pour compléter ce qui aurait pu arriver à la place) et Delete ; Delete all supprime tous les runs sauvegardés avec leur vidéo.
03
Comparer jusqu’à trois runs
Cocher des runs dans la colonne Compare : ils deviennent A, B et C. Leurs moments sont tracés sur des lignes alignées sur le temps du cas d’usage, puis listés par date avec une colonne par run ; un moment qu’un seul run a est en gras, un moment qu’ils ont tous à des dates différentes est décalé. Filtrer par sorte de moment (Actuality, Risk, Deduction, Solution, Task, State, Fork, Task effect) ou cocher Differences only. View process montre le processus d’une solution tel qu’il était alors, avec ce qu’une adaptation a ajouté. How they ended et Resources impacted concluent la comparaison.
04
Un run sur la frise
Timeline dessine un run sous les pistes de TIMELINE : sa ligne d’effets attendus des tâches et sa ligne de problèmes détectés, une ligne par risque ou actualité avec sa probabilité à chaque changement. Pour montrer le run, l’histoire est d’abord redémarrée.
05
Vidéo d’un run
Avec Film the runs coché au-dessus de la scène, la vue 3D est filmée de la première étape à Restart par une caméra automatique : gros plan sur un bien qui change d’état, de dos sur une personne qui se déplace, vue d’ensemble sinon, avec l’heure et une légende sur l’image. La vidéo est gardée avec le run sur le serveur et se regarde ou se télécharge depuis la colonne Scene.
06
Replay
Replay rejoue un run depuis le début de l’histoire avec les réglages de supervision qu’il avait. S’ils diffèrent des réglages actuels, un avertissement les liste (réglage, maintenant, dans ce run) : r-iosemit les écrit dans le projet, pour tous ceux qui y travaillent, et ils restent après le rejeu. C’est le seul endroit où r-iosemit écrit des réglages de r-io suite, et il demande d’abord. Le rejeu est enregistré comme un nouveau run.
07
Cas d’usage : Barbecue
Le scénario Henri Barbecue Story du Barbecue est livré avec trois runs de référence : sans supervision Henri se brûle et se noie, en mode auto Julie le sauve, avec extrapolation Paul éteint le barbecue avant qu’Henri n’arrive. Comparé, le run avec extrapolation montre le risque, la déduction, le déplacement de Paul et l’extinction entre 09:01:34 et 09:02:24, là où le premier run n’a rien.
Les trois runs de référence avec leurs réglages, leurs temps de déduction, leurs moments et leurs vidéos.Sans supervision (A) et avec extrapolation (B) : les moments de chaque run, en gras quand un seul des deux l’a.L’avertissement avant de rejouer le premier run : les réglages qui vont changer, pour tous ceux qui travaillent sur ce projet.
r-iosemit joue le terrain, pas r-io suite. Aucune application r-io suite ne l’appelle ni ne sait qu’il existe : pour r-io suite, chaque événement qu’il joue est réel. Il lit la base de connaissances de r-io suite (états, positions, alertes, risques, tâches) pour choisir ses pistes et enregistrer ses runs, sans jamais écrire ce qu’il lit. Il agit seulement par les canaux du terrain : les capteurs (leurs jeux de données, valeurs planifiées, déplacements GPS et prévisions publiées comme par un fournisseur), les capteurs de messagerie, le service des tâches humaines pour les tâches simulées, et l’API d’horloge du cas d’usage une fois que l’opérateur l’a ouverte dans r-ioga (Edit project › Use case clock › Allow remote clock control).
Quelques éléments de construction agissent directement sur l’espace de connaissances, et les boîtes de dialogue le disent : un niveau de risque planifié (comme le curseur de Potentialities Management), une actualité référencée (une actualité FREEZE rendue ACTIVE, ou un clone d’une actualité REFERENCE), Previous step et Restart (ils restaurent un point de reprise de l’espace de connaissances gardé par le serveur) et Replay (il réécrit les réglages de supervision d’un run, après un avertissement).
