Suchergebnisse

Interoperability and reusability of models are main concerns in military simulation. In order to improve the interoperability and reusability of models, the model shall be separated with a particular simulation engine, and the modelling framework of models as well as the architecture of the simulation engine should be standardized. This paper describes the architecture and operational concept of simulation environment which has been developed to enhance interoperability an d reusability of models. We named this environment adaptive distributed parallel Simulation environment for Interoperable and reusable models (AddSIM). We suggested a modelling framework to promote model development, portability and interoperability with other models. Also, we proposed a layered architecture to modularise critical capabilities including kernel layer, tool/application layer, support/service layer and external interface. This means that models can be developed independently of a simulation engine and interfaced with it using API. To validate the application feasibility of AddSIM, we set up an anti-air missile engagement situation and performed simulation. In military simulation, it is expected that reusability and interoperability of models will be enhanced by using proposed AddSIM.Defence Science Journal, 2012, 62(6), pp.412-419, DOI:http://dx.doi.org/10.14429/dsj.62.1477

Simulationsbasierte Fertigungssteuerung wird in der Praxis eingesetzt, um anhand des Simulationsmodells als Ersatzsystem den zukünftigen Zustand des betrachteten Produktionssystems zu prognostizieren und um im Voraus Maßnahmen zur Behebung zukünftiger Mißstände zu testen. Mit dem in der Arbeit beschriebenen Framework zur simulationsbasierten Fertigungssteuerung steht dem Anwender jetzt ein Unterstützungssystem zur Verfügung, mit dem man ohne Mitwirkung eines Simulationsexperten automatisch ein Simulationsmodell eines komplexen Produktionssystems erstellen und abarbeiten kann. Dadurch gestaltet sich eine Simulationsstudie weniger aufwendig und ist schneller durchführbar. Als Problem verbleibt jedoch, daß mit einer Vielzahl von Parametereinstellungen des Simulationsmodells zu experimentieren ist. Die Laufzeit für die Modellabarbeitung eines Experimentes ist aber z.T. beträchtlich. Primär ergibt sich daher für den Einsatz der simulationsbasierten Fertigungssteuerung ein Zeitproblem. Ein Lösungsansatz dafür ist die Parallele und Verteilte Simulation, welche bereits erfolgreich auf anderen Gebieten eingesetzt wird. Deshalb wurde mit ParSimONY-ProdSys ein Tool zur Parallelen Simulation komplexer Produktionssysteme entwickelt und anschließend in das Unterstützungssystem des Frameworks integriert. Somit ist es erstmals möglich, eine Parallele Simulation von Produktionssystemen durchzuführen. Dabei können die speziellen Prozeßbedingungen realer Produktionssysteme beachtet und komplexe Reihenfolgeplanungsansätze verwendet werden. Für den Einsatz der Parallelen und Verteilten Simulation waren dabei eine Reihe von Problemen zu lösen. U.a. galt es wegen der hohen Unsicherheit über einzusetzende Verfahren und deren Parametrisierung eine Auswahl von Verfahren und Parametern für den Anwendungskontext der simulationsbasierten Fertigungssteuerung von komplexen Produktionssystemen zu treffen. Diese Auswahl wurde durch Untersuchungen an verschiedenen Modellklassen von Produktionssystemen simulativ belegt. Weiterhin wurde auf Basis des Wissens über Modelle von komplexen Produktionssystemen eine Heuristik für die lösungsdefekte Partitionierungsaufgabe konzipiert und in das Framework zur simulationsbasierten Fertigungssteuerung integriert, um den Anwender von dieser bisher manuell im trial-and-error-Verfahren durchgeführten Aufgabe zu entlasten.

A System-on-Chip (SoC) is a complete digital electronic system integrated on a single silicon chip called the hardware. This hardware is usually accompanied by dedicated software, the complexity and development time of which increases year by year. However, the highly competitive environment of SoC design imposes limited time-to-market. It is therefore necessary to develop hardware and software simultaneously in a process called "hardware-software codesign". Since hardware prototypes are initially unavailable, software developers rely on virtual prototypes of the targeted SoC. A virtual prototype is a simulator capable of running the software for the SoC being designed and executable on a conventional computer called the host. The SystemC/TLM-2.0 library is one of the most popular libraries for virtual prototyping of SoC. It allows hardware modeling and simulation using the principle of discrete event simulation (DES). This simulation technique sequentially executes the various processes representing the behavior of the modeled hardware according to the so-called coroutine semantics. This guarantees the reproducibility of the simulations while simplifying the writing of the models. However, DES also constrains the use of a single host core, greatly limiting simulation speed. This thesis proposes a parallelization technique for SystemC loosely timed TLM simulation that preserves coroutine semantics. SCale 2.0, the proposed parallel SystemC kernel, is based on the parallel evaluation of the processes of each evaluation phase as well as on the observation of their interactions, mainly via shared memory. Each shared resource is thus associated with a state machine designed to classify these resources and to define the access policy to them. Thus, each process can possibly be sequentialized before accessing a certain shared resource to prevent any interaction with other processes, which could violate the semantics of coroutines. In spite of this, dependencies can form between processes, for example when accessing the same memory address. In particular, in case of circular dependency between processes called conflict, the coroutine semantics is no longer respected and the simulation becomes invalid. All interactions are therefore controlled at the end of each evaluation phase to validate its evaluation. The storage of these dependencies also allows to replay a simulation identically. In the event of an error, a backtracking is performed using a CRIU-based Linux process backup and restore system to re-execute the simulation and avoid the error. However, the simulation of a complete operating system such as Linux generates a very high number of conflicts in this configuration, the cost of which cancels the benefits obtained by parallelization. As the conflicts are mostly caused by the operating system code itself, it was decided to detect the latter via the privilege level of the simulated processors and to force the sequential simulation of the operating system code. This method was evaluated on a variety of models composed of 1 to 32 simulated RISC-V cores, running benchmarks with and without Linux and simulated on a dual-processor machine with 36 cores. In the parallel simulation of 32 cores, the speedup against the reference SystemC Accellera kernel was up to x15 on the benchmarks without Linux with speeds between 800 and 2000 million simulated instructions per second. The speedup varies between x9 and x13 for Linux-based benchmarks and between x12 and x24 when replaying these simulations ; Un système sur puce (SoC) est un système électronique numérique complet intégré sur une unique puce de silicium appelée le matériel. Ce matériel est généralement assorti d'un logiciel dédié dont la complexité et le temps de développement augmentent d'année en année. Le contexte hautement concurrentiel de la conception de systèmes sur puce impose cependant des temps de mise sur le marché restreints. Il est de ce fait nécessaire de recourir au développement simultané du matériel et du logiciel au sein d'un processus dénommé "hardware-software codesign". Les prototypes matériels étant initialement indisponibles, les développeurs logiciel s'appuient sur des prototypes virtuels du SoC visé. Un prototype virtuel est un simulateur capable d'exécuter le logiciel destiné au SoC en cours de conception et exécutable sur un ordinateur conventionnel appelé l'hôte. La bibliothèque SystemC/TLM-2.0 est parmi les plus populaires pour le prototypage virtuel de SoC. Elle permet la modélisation du matériel ainsi que sa simulation suivant le principe de la simulation à événements discrets (DES). Cette technique de simulation exécute séquentiellement les divers processus représentant le comportement du matériel modélisé d'après la sémantique dite de coroutines. Cela garanti la reproductibilité des simulations tout en simplifiant l'écriture des modèles. Cependant, la DES contraint également à l'utilisation d'un unique cœur de l'hôte, limitant grandement la vitesse de simulation. Cette thèse propose une technique de parallélisation de simulation SystemC à temps dit relâché et qui préserve la sémantique de coroutine. SCale 2.0, le noyau SystemC parallèle proposé, repose sur l'évaluation parallèle des processus de chaque phase d'évaluation ainsi que sur l'observation de leurs interactions, principalement via mémoire partagée. Chaque ressource partagée est ainsi associée à une machine-à-états conçue afin de classifier ces ressources et de définir la politique d'accès à ces dernières. Ainsi, chaque processus peut éventuellement être séquentialité avant l'accès à une certaine ressource partagée afin d'empêcher toute interaction avec les autres processus, ce qui risquerait de violer la sémantique de coroutines. Malgré cela, des dépendances peuvent se former entre les processus, lors de l'accès à une même adresse mémoire par exemple. En particulier, en cas de dépendance circulaire entre processus appelée conflit, la sémantique de coroutine n'est plus respectée et la simulation devient invalide. L'intégralité des interactions est donc contrôlée à l'issue de chaque phase d'évaluation afin de valider son bon déroulement. Le stockage de ces dépendances permet aussi de rejouer une simulation à l'identique. En cas d'erreur, un retour en arrière est opéré à l'aide d'un système de sauvegarde et restauration de processus Linux basé sur CRIU afin de réexécuter la simulation en évitant l'erreur. La simulation d'un système d'exploitation complet tel que Linux engendre cependant dans cette configuration un nombre très important de conflits dont le coût annule les bénéfices obtenus par parallélisation. Les conflits étant très majoritairement causés par le code du système d'exploitation lui-même, il a été choisi de détecter ce dernier via le niveau de privilège des processeurs simulés et de forcer la simulation séquentielle du code du système d'exploitation. Cette méthode a été évaluée sur une variété de modèles composés de 1 à 32 cœurs RISC-V simulés, exécutant des benchmarks avec et sans Linux et simulés sur une machine biprocesseur comportant 36 cœurs. Lors de la simulation parallèle de 32 cœurs, les gains de performance (speedup) face au noyau SystemC de référence Accellera atteignent alors x15 sur les benchmarks sans Linux avec des vitesses entre 800 et 2000 millions d'instructions simulées par seconde. Le speedup varie entre x9 et x13 dans le cas des benchmarks s'appuyant sur Linux et entre x12 et x24 en rejouant ces simulations

A System-on-Chip (SoC) is a complete digital electronic system integrated on a single silicon chip called the hardware. This hardware is usually accompanied by dedicated software, the complexity and development time of which increases year by year. However, the highly competitive environment of SoC design imposes limited time-to-market. It is therefore necessary to develop hardware and software simultaneously in a process called "hardware-software codesign". Since hardware prototypes are initially unavailable, software developers rely on virtual prototypes of the targeted SoC. A virtual prototype is a simulator capable of running the software for the SoC being designed and executable on a conventional computer called the host. The SystemC/TLM-2.0 library is one of the most popular libraries for virtual prototyping of SoC. It allows hardware modeling and simulation using the principle of discrete event simulation (DES). This simulation technique sequentially executes the various processes representing the behavior of the modeled hardware according to the so-called coroutine semantics. This guarantees the reproducibility of the simulations while simplifying the writing of the models. However, DES also constrains the use of a single host core, greatly limiting simulation speed. This thesis proposes a parallelization technique for SystemC loosely timed TLM simulation that preserves coroutine semantics. SCale 2.0, the proposed parallel SystemC kernel, is based on the parallel evaluation of the processes of each evaluation phase as well as on the observation of their interactions, mainly via shared memory. Each shared resource is thus associated with a state machine designed to classify these resources and to define the access policy to them. Thus, each process can possibly be sequentialized before accessing a certain shared resource to prevent any interaction with other processes, which could violate the semantics of coroutines. In spite of this, dependencies can form between processes, for example when accessing the same memory address. In particular, in case of circular dependency between processes called conflict, the coroutine semantics is no longer respected and the simulation becomes invalid. All interactions are therefore controlled at the end of each evaluation phase to validate its evaluation. The storage of these dependencies also allows to replay a simulation identically. In the event of an error, a backtracking is performed using a CRIU-based Linux process backup and restore system to re-execute the simulation and avoid the error. However, the simulation of a complete operating system such as Linux generates a very high number of conflicts in this configuration, the cost of which cancels the benefits obtained by parallelization. As the conflicts are mostly caused by the operating system code itself, it was decided to detect the latter via the privilege level of the simulated processors and to force the sequential simulation of the operating system code. This method was evaluated on a variety of models composed of 1 to 32 simulated RISC-V cores, running benchmarks with and without Linux and simulated on a dual-processor machine with 36 cores. In the parallel simulation of 32 cores, the speedup against the reference SystemC Accellera kernel was up to x15 on the benchmarks without Linux with speeds between 800 and 2000 million simulated instructions per second. The speedup varies between x9 and x13 for Linux-based benchmarks and between x12 and x24 when replaying these simulations ; Un système sur puce (SoC) est un système électronique numérique complet intégré sur une unique puce de silicium appelée le matériel. Ce matériel est généralement assorti d'un logiciel dédié dont la complexité et le temps de développement augmentent d'année en année. Le contexte hautement concurrentiel de la conception de systèmes sur puce impose cependant des temps de mise sur le marché restreints. Il est de ce fait nécessaire de recourir au développement simultané du matériel et du logiciel au sein d'un processus dénommé "hardware-software codesign". Les prototypes matériels étant initialement indisponibles, les développeurs logiciel s'appuient sur des prototypes virtuels du SoC visé. Un prototype virtuel est un simulateur capable d'exécuter le logiciel destiné au SoC en cours de conception et exécutable sur un ordinateur conventionnel appelé l'hôte. La bibliothèque SystemC/TLM-2.0 est parmi les plus populaires pour le prototypage virtuel de SoC. Elle permet la modélisation du matériel ainsi que sa simulation suivant le principe de la simulation à événements discrets (DES). Cette technique de simulation exécute séquentiellement les divers processus représentant le comportement du matériel modélisé d'après la sémantique dite de coroutines. Cela garanti la reproductibilité des simulations tout en simplifiant l'écriture des modèles. Cependant, la DES contraint également à l'utilisation d'un unique cœur de l'hôte, limitant grandement la vitesse de simulation. Cette thèse propose une technique de parallélisation de simulation SystemC à temps dit relâché et qui préserve la sémantique de coroutine. SCale 2.0, le noyau SystemC parallèle proposé, repose sur l'évaluation parallèle des processus de chaque phase d'évaluation ainsi que sur l'observation de leurs interactions, principalement via mémoire partagée. Chaque ressource partagée est ainsi associée à une machine-à-états conçue afin de classifier ces ressources et de définir la politique d'accès à ces dernières. Ainsi, chaque processus peut éventuellement être séquentialité avant l'accès à une certaine ressource partagée afin d'empêcher toute interaction avec les autres processus, ce qui risquerait de violer la sémantique de coroutines. Malgré cela, des dépendances peuvent se former entre les processus, lors de l'accès à une même adresse mémoire par exemple. En particulier, en cas de dépendance circulaire entre processus appelée conflit, la sémantique de coroutine n'est plus respectée et la simulation devient invalide. L'intégralité des interactions est donc contrôlée à l'issue de chaque phase d'évaluation afin de valider son bon déroulement. Le stockage de ces dépendances permet aussi de rejouer une simulation à l'identique. En cas d'erreur, un retour en arrière est opéré à l'aide d'un système de sauvegarde et restauration de processus Linux basé sur CRIU afin de réexécuter la simulation en évitant l'erreur. La simulation d'un système d'exploitation complet tel que Linux engendre cependant dans cette configuration un nombre très important de conflits dont le coût annule les bénéfices obtenus par parallélisation. Les conflits étant très majoritairement causés par le code du système d'exploitation lui-même, il a été choisi de détecter ce dernier via le niveau de privilège des processeurs simulés et de forcer la simulation séquentielle du code du système d'exploitation. Cette méthode a été évaluée sur une variété de modèles composés de 1 à 32 cœurs RISC-V simulés, exécutant des benchmarks avec et sans Linux et simulés sur une machine biprocesseur comportant 36 cœurs. Lors de la simulation parallèle de 32 cœurs, les gains de performance (speedup) face au noyau SystemC de référence Accellera atteignent alors x15 sur les benchmarks sans Linux avec des vitesses entre 800 et 2000 millions d'instructions simulées par seconde. Le speedup varie entre x9 et x13 dans le cas des benchmarks s'appuyant sur Linux et entre x12 et x24 en rejouant ces simulations

In Parallel programming, a programmer needs to understand hardware environment, programming paradigm and primitives available in the programming language. Most of the time, parallel programmes are written for a specific architecture and cannot typically adapt to other architectures Particularly, programs written for shared memory architectures are unsuitable for distributed or hybrid architectures. This paper proposes Adaptive Design Pattern for Parallel Programming to improve adaptability, flexibility with achieving performance on different architectures.
Molecular Dynamics (MD) simulation is required to scale to various architectures from simple machine to cluster of workstations. In this study, MD Simulation experimented using both pure benchmark code and code based on adaptive design patterns. Redesigned MD Simulation with Adaptive Design Pattern claims parallel efficiency from 56% to 90% for different number of processing elements used. The solution demonstrates adaptability to different architectures and scalability to use with large number of atoms and long duration simulation.

Simulation models are widely used in risk analysis to study the effects of uncertainties on outcomes of interest in complex problems. Often, these models are computationally complex and time consuming to run. This latter point may be at odds with time‐sensitive evaluations or may limit the number of parameters that are considered. In this article, we give an introductory tutorial focused on parallelizing simulation code to better leverage modern computing hardware, enabling risk analysts to better utilize simulation‐based methods for quantifying uncertainty in practice. This article is aimed primarily at risk analysts who use simulation methods but do not yet utilize parallelization to decrease the computational burden of these models. The discussion is focused on conceptual aspects of embarrassingly parallel computer code and software considerations. Two complementary examples are shown using the languages MATLAB and R. A brief discussion of hardware considerations is located in the Appendix.

Current military affairs indicate that future military warfare requires safer, more accurate, and more fault-tolerant weapons systems. Unmanned Aerial Vehicles (UAV) are one answer to this military requirement. Technology in the UAV arena is moving toward smaller and more capable systems and is becoming available at a fraction of the cost. Exploiting the advances in these miniaturized flying vehicles is the aim of this research. How are the UAVs employed for the future military? The concept of operations for a micro-UAV system is adopted from nature from the appearance of flocking birds, movement of a school of fish, and swarming bees among others. All of these natural phenomena have a common thread: a global action resulting from many small individual actions. This "emergent behavior" is the aggregate result of many simple interactions occurring within the flock, school, or swarm. In a similar manner, a more robust weapon system uses emergent behavior resulting in no "weakest link" because the system itself is made up of simple interactions by hundreds or thousands of homogeneous UAVs. The global system in this research is referred to as a swarm. Losing one or a few individual unmanned vehicles would not dramatically impact the "swarms" ability to complete the mission or cause harm to any human operator. Swarming reconnaissance is the emergent behavior of swarms to perform a reconnaissance operation. An in-depth look at the design of a reconnaissance swarming mission is studied. A taxonomy of passive reconnaissance applications is developed to address feasibility. Evaluation of algorithms for swarm movement, communication, sensor input/analysis, targeting, and network topology result in priorities of each model's desired features. After a thorough selection process of available implementations, a subset of those models are integrated and built upon resulting in a simulation that explores the innovations of swarming UAVs.