Robert Siegfried

Scenarios play an important role in planning, engineering and executing a - possibly distributed - simulation environment. Unfortunately, in our experience, understanding, documentation and usage of scenarios vary greatly.

Therefore, during planning and setup of a distributed simulation environment scenarios are regularly a source of confusion and manifold problems may arise out of this situation. Typical examples and observed problems include misunderstandings due to a missing common… Show more

Scenarios play an important role in planning, engineering and executing a - possibly distributed - simulation environment. Unfortunately, in our experience, understanding, documentation and usage of scenarios vary greatly.

Therefore, during planning and setup of a distributed simulation environment scenarios are regularly a source of confusion and manifold problems may arise out of this situation. Typical examples and observed problems include misunderstandings due to a missing common definition of “scenario” as well as incomplete or inconsistent scenario descriptions. On the other hand, complete and consistent scenario descriptions will, in turn, lead to simulation environments which are appropriate for the original purpose and fulfill the necessary validity and fidelity requirements.

Firstly, this paper gives an overview of currently available definitions of the term “scenario” and highlights their relations. As the selection, definition, elaboration and refinement of scenarios is a recurring task during the engineering process of a simulation environment, we present a set of definitions for the various types of scenarios encountered during the engineering process and explain in detail the differences between the various types of scenarios and the relation of the various types of scenarios to DSEEP steps.

Secondly, this paper presents our thoughts on necessary scenario documentation. Based on both practical experiences as well as literature research, we present a comprehensive set of documentation items for specifying military scenarios. Finally, we highlight the importance of a formal scenario specification (e.g., using MSDL). Based on the scenario documentation items presented before, we give an overview of the current status of available formal scenario specifications and point out some features currently missing in available formal scenario specifications. Show less

The integration of Live, Virtual, and Constructive (LVC) simulations is already used extensively for training and experimentation. In order to guarantee high-quality results manifold validity requirements are imposed on such couplings. With regard to military training and experimentation fair fight requirements regularly deserve special attention. Fair fight requirements are part of the validity requirements and as such they need to be addressed on all levels of interoperability (i.e. on… Show more

The integration of Live, Virtual, and Constructive (LVC) simulations is already used extensively for training and experimentation. In order to guarantee high-quality results manifold validity requirements are imposed on such couplings. With regard to military training and experimentation fair fight requirements regularly deserve special attention. Fair fight requirements are part of the validity requirements and as such they need to be addressed on all levels of interoperability (i.e. on technical, syntactical, semantic and pragmatic level). Consequently, ensuring fair fight in distributed simulations is one major goal of the VIntEL-development of the German Federal Office of Defense Technology and Procurement (BWB, P1.3, Koblenz). VIntEL (“Verteilte Integrierte Erprobungs-Landschaft”, engl. “Distributed Integrated Test Bed”) is a multi-year effort aiming at increasing the reliability and applicability of distributed simulations and strengthening the credibility of the simulation results.

In this paper, we present at first a thorough definition of fair fight and describe the relations of fair fight and validity requirements in general. Afterwards, we describe the VIntEL architecture which aims at easing the creation of distributed simulations, allows the coupling of simulation systems with real systems (e.g. C2 systems, sensors, or weapon platforms) and how the VIntEL architecture contributes to ensuring fair fight. As fair fight cannot be completely achieved with technical measures only, we present the tight integration of fair fight issues into the VEVA procedure model. We describe how interoperability criteria relevant to fair fight are identified, structured and integrated in the VEVA. Within the VIntEL development actual checklists are derived from these interoperability criteria. By presenting these checklists we demonstrate how fair fight issues may be addressed in a practical and manageable way. Show less

The Distributed Simulation Engineering and Execution Process (DSEEP) developed by SISO and lately standardized as IEEE 1730 is a high-level framework for planning and executing a distributed simulation. Due to this high-level approach, the DSEEP needs to be adapted to specific organizational needs and individual applications.

VEVA is the approach of the German Armed Forces towards operationalizing the DSEEP, providing a very detailed, yet tailorable, procedure model which tries to guide… Show more

The Distributed Simulation Engineering and Execution Process (DSEEP) developed by SISO and lately standardized as IEEE 1730 is a high-level framework for planning and executing a distributed simulation. Due to this high-level approach, the DSEEP needs to be adapted to specific organizational needs and individual applications.

VEVA is the approach of the German Armed Forces towards operationalizing the DSEEP, providing a very detailed, yet tailorable, procedure model which tries to guide the users as much as possible. Similar to the DSEEP, the VEVA defines phases and activities to be carried out for planning, executing and analyzing a distributed simulation. Furthermore, the VEVA includes an role model, defining in-depth the responsibilities and duties of all involved parties. To ensure that all critical aspects are taken care of (and documented), the VEVA provides an extensive set of documentation guidelines.

Firstly, this paper gives a very brief overview of the VEVA (process and documentation guidelines). Secondly, the main contribution of this paper is a detailed comparison of the DSEEP and the VEVA. This includes a comparison of the phases and activities as well as a comparison of activity outcomes specified by these processes. Especially with regard to the activity outcomes, the extensions of VEVA compared to the DSEEP (e.g. documentation guidelines) are highlighted. A major finding is that the DSEEP and the VEVA have many similarities and do not contradict each other. Show less

Das Requirements Engineering (RE) ist im Rahmen der Projektabwicklung ein Schlüsselfaktor, da die RE-Methodiken den Projektbeteiligten strukturierte Vorgehensweisen an die Hand geben, die die Projektzielerreichung hinsichtlich Termin, Kosten und Qualität signifikant unterstützen.

RE darf jedoch nicht als singuläre Projektaktivität verstanden werden. Stattdessen erscheint es uns wichtig, darauf hinzuweisen, dass das RE (d.h. die Erhebung, Dokumentation, Prüfung, Abstimmung und Verwaltung… Show more

Das Requirements Engineering (RE) ist im Rahmen der Projektabwicklung ein Schlüsselfaktor, da die RE-Methodiken den Projektbeteiligten strukturierte Vorgehensweisen an die Hand geben, die die Projektzielerreichung hinsichtlich Termin, Kosten und Qualität signifikant unterstützen.

RE darf jedoch nicht als singuläre Projektaktivität verstanden werden. Stattdessen erscheint es uns wichtig, darauf hinzuweisen, dass das RE (d.h. die Erhebung, Dokumentation, Prüfung, Abstimmung und Verwaltung von Anforderungen) als kontinuierlicher Prozess entlang der gesamten Lebensdauer eines Systems etabliert wird. Nur ein kontinuierliches RE erlaubt die geordnete Weiterentwicklung komplexer Systeme und trägt zudem erheblich zu einer vollständigen Systemdokumentation bei. Hierbei ist im Einzelfall für jedes System bzw. Projekt zu entscheiden, wie viel RE betrieben werden soll. Die Anpassungen hinsichtlich des Umfangs der RE-Maßnahmen sollten dabei nicht in der Breite erfolgen (d.h. durch Weglassen ganzer RE-Aktivitäten), sondern in der Tiefe (d.h. durch eine projekt-spezifisch sinnvolle Anpassung der notwendigen RE-Prozesse sowie des Dokumentationsumfangs der einzelnen Anforderungen). Show less