OneSAF Core Vs Extension

1
OneSAFCore Vs Extension
One Semi-Automated Force (OneSAF)
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 packagenet.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 packagenet.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 extensions
  functionality will not be a part of that OneSAF
  instance.

7
Extension(Separate but not External)

• 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

10
Build Configurations
Domestic Release
SECore Release
Domestic Minus Release
International Release
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/ltext
  _namegtwhere ltext_namegt 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

OneSAF Core
Navy Extension
Models Enginenet/onesaf/core/models Data
Wrappersnet/onesaf/core/services/data/wrappers P
AIR Datanet/onesaf/core/pair
Models Enginenet/onesaf/ext/navy/models Data
Wrappersnet/onesaf/ext/navy/services/data/wrapper
s 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,ltinclude nameext.base.path
/navy/ext.build.name/gt
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.

Future
20
Future Development(Planned Extension Framework
Enhancements)
Future
Future
OneSAF Core
Inter-national
Navy
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.