OneSAF Core Vs Extension

1. One Semi-Automated Force (OneSAF) OneSAFCore Vs Extension

2. Agenda • What is the OneSAF Core? • What is a OneSAF Extension? • Are extensions external to OneSAF? • What constitutes a OneSAF Build? • When do I build a OneSAF Extension? • Extensions and the PAIR. • When do I update the OneSAF Core? • Are extensions ever promoted to core? • Limitations of the current OneSAF Extension Framework. • Future extensions framework changes.

3. OneSAF Core • The OneSAF Core includes the basic services necessary to allow for the loading of simulation services, tools, models, and models’ data. • Every instance of OneSAF will contain the OneSAF Core. The core and its services are guaranteed to be available for all extensions. • The OneSAF Core shall at no time have a dependency on any OneSAF Extension. • OneSAF Core Java package:net.onesaf.core

4. OneSAF Core OneSAF Core Base functionality. Currently releasable to all domestic consumers of OneSAF. Future version of the core will be releasable to all consumers.(Future Development for details.)

5. OneSAF Extension • OneSAF Extensions may contain either software implementations, model data, or both. • OneSAF Extensions may add new functionality, enhance existing functionality, or override existing functionality in the OneSAF Core. • A OneSAF Extension is the primary means to add new functionality to OneSAF. • OneSAF Extension Java base package:net.onesaf.ext

6. Extension(Separate but not External) • OneSAF Extensions are not “external” to OneSAF. When compiled in, an extension becomes a part of the built instance of OneSAF. • However, extensions as a whole may or may not be built into an instance of OneSAF. (via the build option –e) • Extensions that are not built into a OneSAF instance are not active. That extension’s functionality will not be a part of that OneSAF instance.

7. Extension(Separate but not External) OneSAF Core Navy SMDC FCS C2 Robot OS2 OneSAF w/ extensions.

8. Extension Rules • Extensions may extend the functionality of the core. • Extensions may extend the functionality of other extensions. • The core may NOT extend the functionality of extensions.

9. OneSAF Build • The OneSAF domestic default build is the pre-compiled released version of OneSAF this is distributed on the installation DVDs. • As of V3.0, the default build includes the OneSAF Core and the following extensions: • Navy • SMDC • FCS • C2 • Robotics • OS2 OneSAF Core Navy SMDC FCS C2 Robot OS2

10. Build Configurations OneSAF Core Navy OneSAF Core Navy SMDC SMDC FCS FCS C2 SECore Release Domestic Release C2 Robot Domestic Minus Release International Release Robot OneSAF Core OneSAF Core Navy Navy OS2 SMDC OS2 SECore C2 Robot OS2

11. Creating an Extension • Both the OneSAF Core and OneSAF Extensions reside, unbuilt, within the SWR repository. This includes both software implementations and data sets. • During the build process, the software implementations from the core and all compiled in extensions are merged into the SCR repository. All data sets from the core and all compiled in extensions are merged into the PAIR repository. • Since the development of the Extension Framework, the PAIR is no longer a single monolithic entity. It is constructed from the core and the selected extensions. This is referred to as the dynamic PAIR.

12. Creating an Extension • Extensions reside in /SWR/src/net/onesaf/ext/<ext_name>where <ext_name> is the name of the extension. A Java package naming convention acceptable representation of the extension. • For example, the Navy extension lives at:/SWR/src/net/onesaf/ext/navy

13. Creating an Extension • Once the directory has been created, the path (Java package structure) under the extension should correlate to the core equivalent. • For example, equivalent structures between core and the Navy extension: Navy Extension OneSAF Core Models Enginenet/onesaf/core/models Data Wrappersnet/onesaf/core/services/data/wrappers PAIR Datanet/onesaf/core/pair Models Enginenet/onesaf/ext/navy/models Data Wrappersnet/onesaf/ext/navy/services/data/wrappers PAIR Datanet/onesaf/ext/navy/pair

14. Creating an Extension • Once the extension has been created in /SWR/net/onesaf/ext, update the confdb.csv to include the new extension. • For example, the Navy extension entry in confdb.csv: • Where the first field is the short name (usually extension package name), second field is the description, and final field is the extension location. navy,Navy Extension,<include name=“${ext.base.path}/navy/${ext.build.name}”/>

15. Creating an Extension • As stated above, the PAIR is now dynamically created from the core and the selected extensions. • Therefore, any component, entity, unit, and/or behavior compositions created for the extension with the composer tools must be copied from the PAIR directory to the extension. • Once in the extension, the manifest.csv file must be updated to copy the new compositions into the PAIR when the baseline is next built.

16. Updating OneSAF Core • OneSAF must meet the training and analysis needs of many customers. • Quite often the requirements from one customer will not be compatible with those from another customer. • Therefore, as a guiding principal, updates to the OneSAF Core are made when: • Problems are discovered in the core (PTRs). • When the visibility or scope of core. functionality needs to be updated to facilitate extending via a new extension. • Enhancements are needed to core services or tools that cannot be made via an extension.

17. Promoted To The Core • Co-Developers are encouraged to develop to an extension. • However, co-developers are also asked to enumerate any functionality during the handover that they feel might benefit the community as a whole. • OneSAF Architecture and Integration will consider all extensions for promotion to core. • If deemed a benefit to the OneSAF community as a whole and releasable to the entire OneSAF community, all or part of an extension may be promoted into the core.

18. Limitations of Extensions • The current extension framework is not without its limitations. • There is no resolution or warning about conflicts between different extensions (software implementation or data sets). • Extensions cannot express dependency on other extensions or services provided by an extension. • There is no guaranteed build order of extensions or expression of dependencies between extensions. • OneSAF tools are not aware of extensions (i.e., MCT and the composers) • Behavior metadata is tracked only on the core file. • Building the OneSAF baseline with all the extensions is discouraged.

19. Future Development(Planned Extension Framework Enhancements) • Software implementation, models, and models data that cannot be released to international audiences will be refactored into an extension to facilitate the release of an international instance of OneSAF. • Additionally, any gaps created in the core could be filled by an international extension. OneSAF Core Domestic Navy OneSAF Core SMDC Navy Domestic FCS SMDC C2 FCS Future Robot C2 OS2 Robot OS2

20. Future Development(Planned Extension Framework Enhancements) Future OneSAF Core Domestic Future Navy OneSAF Core OneSAF Core Inter-national SMDC Navy Domestic Navy FCS SMDC C2 FCS Robot C2 OS2 Robot OS2

21. Future Development(Planned Extension Framework Enhancements) • There are plans to update the core framework to support building all the extensions all the time. Extensions would be selected at runtime vs build time. • Processes, metadata, and documentation methods to allow extensions to express dependencies on other extensions, extension contents, services provided, and services overridden / modified. This will allow the build process to determine proper extension build ordering and conflict notification. • Updates to tools and further updates to core services to fully support extensions.