High Level Architecture

Last updated

The High Level Architecture (HLA) is a standard for distributed simulation, used when building a simulation for a larger purpose by combining (federating) several simulations. [1] The standard was developed in the 1990s under the leadership of the US Department of Defense [2] and was later transitioned to become an open international IEEE standard. It is a recommended standard within NATO through STANAG 4603. [3] Today the HLA is used in a number of domains including defense and security and civilian applications.

Contents

The purpose of HLA is to enable interoperability and reuse. Key properties of HLA are:

HLA forms the basis for developing standardized and extendable FOMs in different communities, for example in aerospace and defense.

The architecture specifies the following components.

Components of an HLA federation HLA Federation.png
Components of an HLA federation

Together the above components form a Federation.

The HLA standard consists of three parts:

  1. IEEE Std 1516-2010 Framework and Rules, [4] which specifies ten architectural rules that the components or the entire federation shall adhere to.
  2. IEEE Std 1516.1-2010 Federate Interface Specification, [5] which specifies the services that shall be provided by the RTI. The services are provided as C++ and Java APIs as well as Web Services.
  3. IEEE Std 1516.2-2010 Object Model Template Specification, [6] which specifies the format that HLA object models, such as the FOM, shall use.

History and versions

HLA was initiated in the early 1990s when Dr. Anita K. Jones, the Director of Defense Research and Engineering within the US Department of Defense, gave the Defense Modeling and Simulation Office (DMSO) the task of “assuring interoperability and reusability of defense models and simulations”. [1] In 1995 DMSO formulated a vision for modeling and simulation and established a modeling and simulation masterplan, which included the High Level Architecture.

Two protocols for M&S interoperability already existed: Distributed Interactive Simulation (DIS), focusing on real-time platform level simulation with a fixed object model, and Aggregate Level Simulation Protocol (ALSP) focusing on simulation of aggregate with time management, ownership management and flexible object models, called confederation models. The purpose of HLA was to provide one unified standard that would meet the simulation interoperability requirements of all US DoD components. [2]

The development of HLA was based on four prototypical federations: the Platform Prototype Federation, the Joint Training Protofederation, the Analysis Protofederation and the Engineering Prototype Federation. The HLA specification was prototyped and refined, until HLA 1.3 was finally released. To facilitate usage outside of the defense community, HLA was then transitioned into an IEEE standard, maintained by Simulation Interoperability Standards Organization (SISO). To facilitate the migration for DIS users, a Federation Object Model corresponding to the fixed object model of DIS was also developed as the Real-time Platform Reference FOM (RPR FOM).

The following HLA versions exist:

HLA 1.3

HLA 1.3 was published in March 1998 by DMSO. It consists of:

The US DoD also published interpretations for HLA 1.3:

HLA 1516-2000

HLA IEEE 1516-2000 was published in 2000 by IEEE. It consists of:

Major improvements in IEEE 1516-2000 included an XML-based FOM with detailed data type specifications, as well as an improved DDM design.

The IEEE 1516-2000 standard was also complemented by a recommended development process as well as a recommended VV&A process:

It was soon found that the 1516-2000 standard had APIs that were slightly different for each RTI implementation. SISO produced a standard with alternate, dynamic link compatible (DLC) C++ and Java APIs:

The DLC APIs were later merged into the main standard.

HLA 1516-2010 (HLA Evolved)

The IEEE 1516-2010 standard was published in August 2010 by IEEE and is commonly known as HLA Evolved. [7] It consists of:

Major improvements in IEEE 1516-2010 include Modular FOMs, [8] incorporation of the DLC APIs in C++ and Java, a Web Services API [9] and Fault Tolerance. [10]

Machine-readable parts of this version of HLA, such as XML Schemas, C++, Java and WSDL APIs as well as FOM/SOM samples can be downloaded from the IEEE 1516 download area of the IEEE web site. The full standards texts are available at no cost to SISO members or can be purchased from the IEEE shop.

HLA 1516-20XX (HLA 4)

The development of a new version of HLA started in January 2016 by SISO and is currently ongoing.

Technical overview

The HLA standard consists of three parts:

Common HLA terminology

Interface specification

The RTI services are defined in the HLA Interface Specification. They are grouped into seven service groups. In addition to these services, the Management Object Model (MOM) provides services that makes it possible to inspect and adjust the state of the federation programmatically.

Most RTIs consist of a Central RTI Component (CRC), which is an executable and Local RTI Components (LRCs), which are libraries that are used by the federates. Services are provided through a C++ or Java API and also using Web services. In the C++ and Java APIs, services are invoked using calls to an instance of the RTI Ambassador class. The RTI delivers information to a federate using callbacks, which are delivered using calls to an instance of the Federate Ambassador class. In the Web Services API, defined using WSDL, calls are made, and callbacks are fetched, by the federate using Web Services requests and responses.

The service group descriptions below focus on key services. Exceptions and advisories are not included.

Federation Management Services

The purpose of Federation Management services, described in chapter 4 of the HLA Interface Specification, [5] is to manage Federation Executions as well as federation-wide operations such as Synchronization Points and Save/Restore.

One set of Federation Management services manages the connection to the RTI, the federation execution and the set of joined federates. Key services are:

Another set of services relates to synchronization points. These are federation-wide events where all, or selected federates are required to complete an operation, such as initializing a scenario, before the execution can continue. Key services are:

Yet another set of service relates to saving and restoring a federation execution. A save operation requires both the RTI and each federate to perform a save of their internal state. A restore operation requires both the RTI and each federate to perform a restore of their internal state. Key services are:

Save:

Restore:

Declaration Management Services

The purpose of Declaration Management services, described in chapter 5 of the HLA Interface Specification, [5] is to enable federates to declare what information they wish to publish (send) and subscribe to (receive) based on object and interaction classes in the FOM. The RTI uses this information to route updates and interactions to subscribing federates. For an object class, publishing and subscribing are performed for a specific set of attributes. For interaction classes, the entire interaction, including all parameters, is published and subscribed. Key services are:

Object Management Services

The purpose of Object Management services, described in chapter 6 of the HLA Interface Specification, [5] is to enable federates to share information about object instances and to exchange interactions.

Object instance names can be reserved or be automatically generated. Federates can register object instances of specified object classes, that are then discovered by subscribing federates. Attributes of these object instances can be updated. These updates will be reflected to subscribing federates. Interactions can be sent. These interactions will be delivered to subscribing federates. Key services are:

Objects:

Attributes:

Interactions:

Ownership Management Services

The purpose of Ownership Management services, described in chapter 7 of the HLA Interface Specification, [5] is to dynamically manage what federate that simulates what aspect of an object instance. In HLA, only one federate is allowed to update a given attribute of a given object instance. That federate is considered the owner of the attribute. A federate that registers a new object instance will automatically be the owner of all attributes it publishes. In some cases, attributes of an object instance may become unowned, i.e. not owned by any federate.

Ownership management provides services for transferring ownership of one or several attributes at runtime, which can include a federate Divesting the attribute and another federate Acquiring the attribute. There are two main patterns: “pull” that are initiated by the acquiring federate and “push” that are initiated by the divesting federate.

Key services for initiating “pull” ownership are:

Key services for initiating “push” ownership are:

All object instances have a predefined attribute called HLAPrivilegeToDeleteObject. Only the owner of this attribute for an object instance is allowed to delete the object instance. Ownership of this attribute can be transferred at runtime using the above operations.

Time Management Services

The information exchange in an HLA federation takes place in real-time with immediate (Receive Order, RO) delivery of messages, unless HLA Time Management has been enabled. The purpose of HLA Time Management, described in chapter 8 of the HLA Interface Specification, [5] is to guarantee causality and a correct and consistent exchange of time stamped messages (updates and interactions) in Time Stamp Order (TSO), no matter if the federation executes in real-time, faster-than-real-time, slower-than-real-time or as-fast-as-possible.

Some important concepts in HLA Time Management are:

Logical time: A time axis in HLA, starting at zero. Logical time is used for Time Management timestamps and operations. The logical time axis can be mapped to the scenario time of the federation. An example of such a mapping is to let zero represent the scenario time 8:00 of the 1-Jan-1066 and let an increment by one represent one second of the scenario.

Lookahead: A time interval specifying the lowest time in the future for which a federate will produce messages. For a federate with a fixed time step, this is usually the length of the time step.

Granted: A federate is granted (allowed to advance) to a particular logical time by the RTI, when all time-stamped messages up to that time have been delivered. The federate can then safely start calculating messages with a timestamp in the future. This timestamp may not be earlier than the granted time plus the federates lookahead.

Advancing: When a federate has finished producing data for the granted time plus the lookahead, it may request to be advanced to a later time, which also means that it promises not to produce any more messages with a time stamp less than the requested time plus the lookahead. The federate is now in the advancing state.

Time Regulating: A federate that sends time stamped events is considered Time Regulating since the time advance by other federates may be regulated by this.

Time Constrained: A federate that receives time managed events is considered Time Constrained since the reception of time stamped messages, constrains its time advance.

The main principles of HLA Time Management are that:

Example of Lookahead, granted and advancing:

  1. A federate uses a fixed time step of 10 and has a Lookahead of 10.
  2. The federate is granted to logical time 50 by the RTI. The RTI thus guarantees that all messages with time step less or equal to 50 have been delivered to the federate.
  3. The federate now has all the necessary data to correctly calculate and send messages for the granted time plus Lookahead, i.e. 60.
  4. When the federate has sent all messages with timestamp 60, it requests to be advanced to time 60. It thereby promises not to send any messages with a timestamp less than 70.
  5. The RTI delivers all messages with timestamp less or equal to 60 to the federate. It then grants the federate to time 60.
  6. Etc.

If at least one federate in the federation performs pacing, i.e. correlates their time advance requests with a real time clock, the federation may run in real time or scaled real time. Without pacing, the federation will run as fast as possible (e.g., federations that do not require human interaction at runtime nor interfaces with systems that depend upon a real-time clock can run as fast as computing resources will allow).

Key services include:

For event driven simulation it is also possible for a federate to request to be advanced to the next event using the following service:

Another important concept is Greatest Available Logical Time (GALT). The greatest time that each federate can be granted to, depends on the time that other federates have been granted to as well as their lookahead. The GALT for a federate specifies how far a federate can be granted, without having to wait for other federates to be granted. This is particularly interesting for a federate that joins late into a time managed federation.

Key services for GALT are:

More advanced services include:

Data Distribution Management Services (DDM)

The purpose of DDM, described in chapter 9 of the HLA Interface Specification, [5] is to increase scalability of federations by performing additional filtering of subscribed data beyond class and attribute subscriptions. [11] Filtering can be based on continuous values (like latitude and longitude) or discrete values (like car brand).

Key concepts of DDM are:

Dimension: a named interval (0..n) used for filtering, with values starting with 0 and ending with an upper bound n. Data in the simulation domain is mapped to one or more dimensions. For example, dimensions for geographical filtering could be LatitudeDimension and LongitudeDimension. A dimension for filtering based on car brand could be CarBrandDimension.

Normalization function: a function that maps input values to integer values to be used in a dimension. An example is that a normalization function for the LatitudeDimension could map a latitude value ranging from -90.0 to +90.0 to an integer in the range 0..179. A normalization function for the CarBrandDimension could map a set of car brands Kia, Ford, BMW and Peugeot to an integer in the range 0..3.

Range: an interval on a dimension, specified by a lower bound (inclusive) and an upper bound (exclusive).

Region: a set of ranges, each one relating to a particular dimension. In the above example, a region could consist of the range (3..5) for LatitudeDimension (55..65) for LongitudeDimension and (0..1) for the CarBrandDimension. At runtime Region Realizations (objects) are instantiated to represent regions. The ranges of a region can be modified over time.

Region overlap: two regions overlap if, for all dimensions that they have in common, their ranges overlap.

At runtime, a federate can provide Regions when subscribing to object class attributes and interactions. Regions are also used when sending attribute updates and interactions. When DDM is used, attribute updates and interactions will only be delivered if there is a region overlap.

Key services for Regions are:

Key services for exchanging attribute updates with DDM are:

Key services for exchanging interactions with DDM are:

Support services

The HLA Support Services, described in chapter 10 of the HLA Interface Specification, [5] provide a number of supporting services. These include:

Management Object Model

The purpose of the Management Object Model, described in chapter 11 of the HLA Interface Specification, [5] is to provide services for managing a federation. This is performed using the MOM object and interaction classes. MOM objects are defined in a special FOM module called the MIM, that is automatically loaded by the RTI. Key MOM features include:

Object model template (OMT)

The OMT is a template used for describing Federation Object Models (FOMs) and Simulation Object Models (SOMs). FOMs and SOMs can be represented in a tabular format or using XML. The latter format is used when a FOM is loaded into the RTI.

In earlier versions of HLA, FOMs were monolithic, but the current version of the standard supports modular FOMs, i.e. several modules, covering different aspects of the information exchange, can be provided to the RTI.

A number of predefined classes, datatypes, dimensions and transportation types are provided in the standard. These are provided in the HLAstandardMIM.xml FOM module. Predefined concepts are prefixed with HLA, for example HLAobjectRoot and HLAunicodeString.

There are three different XML Schemas for the OMT:

Identification Table

The purpose of the identification table is to provide meta-data about the model, to facilitate reuse of the FOM/SOM or federates.

Sample HLA identification table Sample HLA Identification Table.png
Sample HLA identification table

The following fields are specified:

Object Classes Structure Table

The purpose of the object class structure table is to specify the class hierarchy (subclass/superclass) of the object classes that are used to instantiate objects in an HLA federation. Object class attributes are inherited from superclasses to subclasses based on this hierarchy. The root of the object class tree is known as HLAobjectRoot. An example of a fully qualified name of an object class is HLAobjectRoot.Car.ElectricCar

Sample HLA object class table Sample HLA object class table.png
Sample HLA object class table

The following fields are specified for an object class in the hierarchy:

Attribute Table

The purpose of the attribute table is to specify the attributes that are available for a given object class. Since attributes are inherited, an object class will have the union of all attributes that are locally defined on the object class or specified on any direct or indirect superclass.

Sample HLA attribute table Sample HLA attribute table.png
Sample HLA attribute table

The following fields are specified for an attribute

Interaction Class Structure Table

The purpose of the interaction class structure table is to specify the class hierarchy (subclass/superclass) of the interaction classes that are used to exchange interactions in an HLA federation. Interaction class parameters are inherited from superclasses to subclasses based on this hierarchy. The root of the interaction class tree is known as HLAinteractionRoot. An example of a fully qualified name of an interaction class is HLAinteractionRoot.CarCommand.Start.

Sample HLA interaction class table Sample HLA interaction class table.png
Sample HLA interaction class table

The following fields are specified for an interaction class in the hierarchy:

Parameter Table

The purpose of the parameter table is to specify the parameters that are available for a given interaction class. Since parameters are inherited, an interaction class will have the union of all parameters that are locally defined on the interaction class or specified on any direct or indirect superclass.

Sample HLA parameter table Sample HLA parameter table.png
Sample HLA parameter table

Dimensions table

The purpose of the dimensions table is to specify the DDM dimensions, used for attributes and interaction classes.

Time representation table

The purpose of the time representation table is to specify the datatypes used by the Time Management services.

User-supplied tag table

A user-supplied tag can be supplied when calling certain HLA services. The purpose of the user-supplied tag table is to specify the datatypes of these tags.

Synchronization table

The purpose of the synchronization table is to specify the synchronisation points used in a federation.

Transportation type table

The purpose of the transportation type table is to specify the available transportation types. There are two predefined transportation types: HLAreliable and HLAbestEffort.

Update rate table

The purpose of the update rate table is to specify the available maximum update rates.

Switches table

The runtime behaviour of the RTI can be controlled using a number of predefined switches. The purpose of the switches table is to provide initial values for these switches. Some of the switches can also be updated at runtime.

Datatypes

The purpose of the datatype tables is to provide specifications of the datatypes used for attributes, parameters, dimensions, time representation, user supplied tag and synchronization points. There are six categories of datatypes, with a separate tabular format for each of them.

Basic Data Representation Table

The purpose of the basic data representation table is to provide binary representations for use in other tables. A number of predefined basic datatypes are provided in the HLA standard: HLAinteger16BE, HLAinteger32BE, HLAinteger64BE, HLAfloat32BE, HLAfloat64BE, HLAoctetPairBE, HLAinteger16LE, HLAinteger32LE, HLAinteger64LE, HLAfloat32LE, HLAfloat64LE, HLAoctetPairLE and HLAoctet. The set of basic datatypes is usually not extended with user defined basic datatypes.

Simple Datatypes Table

Sample HLA simple datatype table Sample HLA simple datatype table.png
Sample HLA simple datatype table

The purpose of the simple datatypes table is to describe simple scalar data items. A number of predefined simple datatypes are provided in the HLA standard: HLAASCIIchar, HLAunicodeChar, HLAbyte, HLAinteger64time and HLAfloat64time. It is common to include user defined simple datatypes in a FOM.

Enumerated Datatypes Table

Sample HLA enumerated datatype table Sample HLA enumerated datatype table.png
Sample HLA enumerated datatype table

The purpose of the enumerated datatypes table is to describe data elements that can take on a finite discrete set of values. One predefined enumerated datatype is provided in the standard: HLAboolean. It is common to include user defined enumerated datatypes in a FOM.

Array Datatypes Table

Sample HLA array datatype table Sample HLA array datatype table.png
Sample HLA array datatype table

The purpose of the enumerated datatypes table is to describe arrays of data elements (simple, enumerated, arrays, fixed records or variant records). A number of predefined simple datatypes are provided in the HLA standard: HLAASCIIstring, HLAunicodeString, HLAopaqueData and HLAtoken. It is common to include user defined array datatypes in a FOM.

Fixed Record Datatypes Table

Sample HLA fixed record datatype table Sample HLA fixed record datatype table.png
Sample HLA fixed record datatype table

The purpose of the fixed record datatypes table is to describe records with a fixed set of data elements (simple, enumerated, arrays, fixed records or variant records).

Variant Record Datatypes Table

The purpose of the variant record datatypes table is to describe records that may contain different, predefined sets of data elements. The different sets are called Alternatives. Which alternative that applies for a given variant record is indicated by a data element called the Discriminant.

Notes table

The purpose of the notes table is to provide annotations and additional descriptions of items in other tables.

HLA rules

The HLA rules describe the responsibilities of federations and the federates that join. [12]

  1. Federations shall have an HLA federation object model (FOM), documented in accordance with the HLA object model template (OMT).
  2. In a federation, all representation of objects in the FOM shall be in the federates, not in the run-time infrastructure (RTI).
  3. During a federation execution, all exchange of FOM data among federates shall occur via the RTI.
  4. During a federation execution, federates shall interact with the run-time infrastructure (RTI) in accordance with the HLA interface specification.
  5. During a federation execution, an attribute of an instance of an object shall be owned by only one federate at any given time.
  6. Federates shall have an HLA simulation object model (SOM), documented in accordance with the HLA object model template (OMT).
  7. Federates shall be able to update and/or reflect any attributes of objects in their SOM and send and/or receive SOM object interactions externally, as specified in their SOM.
  8. Federates shall be able to transfer and/or accept ownership of an attribute dynamically during a federation execution, as specified in their SOM.
  9. Federates shall be able to vary the conditions under which they provide updates of attributes of objects, as specified in their SOM.
  10. Federates shall be able to manage local time in a way that will allow them to coordinate data exchange with other members of a federation.

HLA Evolved

The IEEE 1516 standard has been revised under the SISO HLA-Evolved Product Development Group and was approved 25-Mar-2010 by the IEEE Standards Activities Board. The revised IEEE 1516–2010 standard includes current DoD standard interpretations and the EDLC API, an extended version of the SISO DLC API. Other major improvements include:

Federation Conformance

In order to ensure the proper interaction between simulations, a way of testing federate conformance is defined. This involves ensuring that every class and interaction listed in the SOM for a particular federate is used according to the usage described, "PublishSubscribe", "Publish", "Subscribe" or "None".

STANAG 4603

HLA (in both the current IEEE 1516 version and its ancestor "1.3" version) is the subject of the NATO standardization agreement (STANAG 4603) for modeling and simulation: Modeling And Simulation Architecture Standards For Technical Interoperability: High Level Architecture (HLA). [13]

Base Object Model

The Base Object Model (BOM), SISO-STD-003-2006 is a related standard by SISO to provide better reuse and composability for HLA simulations. It provides a way to specify conceptual models and how to map them to an HLA FOM. [14]

Alternatives

In regards to the Distributed Modeling and Simulation (DM&S) industry the most often used alternative to the HLA, for real-time simulation of military platforms, is Distributed Interactive Simulation (DIS), IEEE 1278.1-2012, a simulation protocol. Most HLA RTI vendors also feature DIS in their products. As for middleware applications that most closely match HLA features, such as the publish and subscribe feature (P&S) see Data Distribution Service (DDS) which shares many of the same characteristics but having an open on-the-wire protocol for system interoperability. [15]

Criticism

HLA is a Message-oriented middleware that defines as a set of services, provided by a C++ or Java API. There is no standardized on-the-wire protocol. Participants in a federation must use RTI libraries from the same provider and usually also of the same version, which in some cases is perceived as a drawback. [16] Most current tools also provide interconnectivity through sockets.

See also

Related Research Articles

In object-oriented programming, a class defines the shared aspects of objects created from the class. The capabilities of a class differ between programming languages, but generally the shared aspects consist of state (variables) and behavior (methods) that are each either associated with an particular object or with all objects of that class.

<span class="mw-page-title-main">Unified Modeling Language</span> Software system design modeling tool

The unified modeling language (UML) is a general-purpose visual modeling language that is intended to provide a standard way to visualize the design of a system.

Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating systems and network interfaces. Application programming interfaces (APIs) that extend across diverse platforms and networks are typically provided by MOM.

Distributed Interactive Simulation (DIS) is an IEEE standard for conducting real-time platform-level wargaming across multiple host computers and is used worldwide, especially by military organizations but also by other agencies such as those involved in space exploration and medicine.

<span class="mw-page-title-main">Run-time infrastructure (simulation)</span>

In simulation, run-time infrastructure (RTI) is a middleware that is required when implementing the High Level Architecture (HLA). RTI is the fundamental component of HLA. It provides a set of software services that are necessary to support federates to coordinate their operations and data exchange during a runtime execution. In other sense, it is the implementation of the HLA interface specification but is not itself part of specification. Modern RTI implementations conform to the IEEE 1516 and/or HLA 1.3 API specifications. These specifications do not include a network protocol for RTI. It is up to the implementors of an RTI to create a specification. Due to this, interoperability between RTI products and often, RTI versions, should not be assumed unless the vendor specifies interoperability with other products or versions.

<span class="mw-page-title-main">Learning object metadata</span> Data model

Learning Object Metadata is a data model, usually encoded in XML, used to describe a learning object and similar digital resources used to support learning. The purpose of learning object metadata is to support the reusability of learning objects, to aid discoverability, and to facilitate their interoperability, usually in the context of online learning management systems (LMS).

The Data Distribution Service (DDS) for real-time systems is an Object Management Group (OMG) machine-to-machine standard that aims to enable dependable, high-performance, interoperable, real-time, scalable data exchanges using a publish–subscribe pattern.

<span class="mw-page-title-main">Class diagram</span> Diagram that describes the static structure of a software system

In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations, and the relationships among objects.

SystemVerilog, standardized as IEEE 1800, is a hardware description and hardware verification language used to model, design, simulate, test and implement electronic systems. SystemVerilog is based on Verilog and some extensions, and since 2008, Verilog is now part of the same IEEE standard. It is commonly used in the semiconductor and electronic design industry as an evolution of Verilog.

A software design description is a representation of a software design that is to be used for recording design information, addressing various design concerns, and communicating that information to the design’s stakeholders. An SDD usually accompanies an architecture diagram with pointers to detailed feature specifications of smaller pieces of the design. Practically, the description is required to coordinate a large team under a single vision, needs to be a stable reference, and outline all parts of the software and how they will work.

<span class="mw-page-title-main">RDFLib</span> Python library to serialize, parse and process RDF data

RDFLib is a Python library for working with RDF, a simple yet powerful language for representing information. This library contains parsers/serializers for almost all of the known RDF serializations, such as RDF/XML, Turtle, N-Triples, & JSON-LD, many of which are now supported in their updated form. The library also contains both in-memory and persistent Graph back-ends for storing RDF information and numerous convenience functions for declaring graph namespaces, lodging SPARQL queries and so on. It is in continuous development with the most recent stable release, rdflib 6.1.1 having been released on 20 December 2021. It was originally created by Daniel Krech with the first release in November, 2002.

A classifier is a category of Unified Modeling Language (UML) elements that have some common features, such as attributes or methods.

<span class="mw-page-title-main">EXPRESS (data modeling language)</span> Standard data modeling language for product data

EXPRESS is a standard for generic data modeling language for product data. EXPRESS is formalized in the ISO Standard for the Exchange of Product model STEP, and standardized as ISO 10303-11.

The Aggregate Level Simulation Protocol (ALSP) is a protocol and supporting software that enables simulations to interoperate with one another. Replaced by the High Level Architecture (simulation) (HLA), it was used by the US military to link analytic and training simulations.

<span class="mw-page-title-main">IDEF4</span>

IDEF4, or Integrated DEFinition for Object-Oriented Design, is an object-oriented design modeling language for the design of component-based client/server systems. It has been designed to support smooth transition from the application domain and requirements analysis models to the design and to actual source code generation. It specifies design objects with sufficient detail to enable source code generation.

The Simulation Interoperability Standards Organization (SISO) is an organization dedicated to the promotion of modeling and simulation interoperability and reuse for the benefit of diverse modeling and simulation communities, including developers, procurers, and users, worldwide.

The Application Interface Specification (AIS) is a collection of open specifications that define the application programming interfaces (APIs) for high-availability application computer software. It is developed and published by the Service Availability Forum and made freely available. Besides reducing the complexity of high-availability applications and shortening development time, the specifications intended to ease the portability of applications between different middleware implementations and to admit third party developers to a field that was highly proprietary in the past.

MAK Technologies, formerly doing business as VT MAK, Inc. is a software company based in Cambridge, Massachusetts that provides commercial off-the-shelf (COTS) modeling and simulation software. The company develops and sells software for distributed simulations that system integrators, governments, and research institutions use to build and populate 3D simulated environments. Users include medical, aerospace, defense, and transportation industries. In addition to offering COTS software, MAK provides the following services: simulation content creation, software customization, interoperability, research and development, and training.

The Real-time Platform Reference Federation Object Model enables linking computer simulations of discrete physical entities into complex virtual worlds. It is a High Level Architecture (HLA) federation object model developed for distributed simulation applications of defense and security. RPR FOM is listed in the NATO Modelling and Simulation Standards Profile AMSP-01.

NGSI-LD is an information model and API for publishing, querying and subscribing to context information. It is meant to facilitate the open exchange and sharing of structured information between different stakeholders. It is used across application domains such as smart cities, smart industry, smart agriculture, and more generally for the Internet of things, cyber-physical systems, systems of systems and digital twins.

References

  1. 1 2 Kuhl, Frederick; Weatherly, Richard; Dahmann, Judith (October 18, 1999). Creating Computer Simulation Systems: An Introduction to the High Level Architecture (1 ed.). Prentice Hall. ISBN   0130225118.
  2. 1 2 Dahmann, Judith (1997). "The Department of Defense High Level Architecture" (PDF). Proceedings of the 29th conference on Winter simulation - WSC '97. pp. 142–149. doi:10.1145/268437.268465. ISBN   078034278X. S2CID   6047580.
  3. ↑ STANAG 4603: Modelling and Simulation Architecture Standards for Technical Interoperability: High Level Architecture (HLA). NATO.
  4. 1 2 IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA)— Framework and Rules. IEEE Computer Society. 18 August 2010. ISBN   978-0-7381-6251-5.
  5. 1 2 3 4 5 6 7 8 9 10 IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA)— Federate Interface Specification. IEEE Computer Society. 18 August 2010. ISBN   978-0-7381-6247-8.
  6. 1 2 IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA)— Object Model Template (OMT) Specification. IEEE Computer Society. 18 August 2010. ISBN   978-0-7381-6249-2. Archived from the original on August 18, 2019.
  7. ↑ Möller, Björn; Morse, Kathrine L; Lightner, Mike; Little, Reed; Lutz, Bob (April 2008). "HLA Evolved – A Summary of Major Technical Improvements". Proceedings of 2008 Spring Simulation Interoperability Workshop.
  8. ↑ Möller, Björn; Löfstrand, Björn (September 2009). "Getting started with FOM Modules". Proceedings of 2009 Fall Simulation Interoperability Workshop.
  9. ↑ Möller, Björn; Löf, Staffan (September 2006). "A Management Overview of the HLA Evolved Web Service API". Proceedings of 2006 Fall Simulation Interoperability Workshop.
  10. ↑ Möller, Björn; Karlsson, Mikael; Löfstrand, Björn (April 2005). "Developing Fault Tolerant Federations using HLA Evolved". Proceedings of 2005 Spring Simulation Interoperability Workshop.
  11. ↑ Möller, Björn; Fredrik, Antelius; Martin, Johansson; Mikael, Karlsson (September 2016). "Building Scalable Distributed Simulations: Design Patterns for HLA DDM". Proceedings of 2016 Fall Simulation Interoperability Workshop. Retrieved 13 November 2019.
  12. ↑ U.S. Defense Modeling and Simulation Office (2001). RTI 1.3-Next Generation Programmer's Guide Version 4. U.S. Department of Defense.
  13. ↑ "High Level Architecture STANAG Development (MSG-033)" . Retrieved March 3, 2015.
  14. ↑ SISO BOM Standard
  15. ↑ Doshi, Rajiv; Castellote, Gerardo-Pardo (2006). "A Comparison of HLA and DDS" (PDF). Real-Time Innovations. Retrieved March 3, 2015.{{cite journal}}: Cite journal requires |journal= (help)
  16. ↑ Granowetter, Len. "RTI Interoperability Issues - API Standards, Wire Standards, and RTI Bridges" . Retrieved 14 March 2018.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.