Simphonie definition file

In this section, the requirements are defined only to link to SMP level clauses subset in order to organize test traceability and provide an overview of the SMP features coverage.

Here are defined some extended SMP featured, that are features not defined by the SMP standard but considered to be needed to create a full featured simulator.

The basic object implementation (object, component, collection, composites) can be shared, but the extended service shall rely only on the standard SMP interface when interacting with the simulator, models, components and other services to be hopefully reusable with any SMP compliant simulation infrastructure.

Of course, such service replacement may alter the way simphonie is working (and that is for that purpose), and the simulator integrator shall be aware of some constraints to keep its simulation system able to run properly:

• some simphonie's services are sharing somehow a contract for a good cooperation. For instance the scheduler and time keeper are cooperating through specific events that are not part of the SMP level 1 standard. Then replacing one of this two service requires the contract is maintained by the replacing service. Or both services that may have their own cooperation scheme shall be overridden.
• The service override is allowed only on the very early stage of the simulator build phase: services shall be added using AddService() method before the Publish step starts. After that the simulator behavior is undefined and the integrator shall assume the resulting behavior can suit its expectations.
• The type registry service is used to load libraries, making possible some types being registered before any service is added, then before a type registry replacement can be set making possible the loss of the early type registrations.

In the next requirements, the service word shall be understood in the extended way of set of feature. When deriving from Smp::IService is needed, specific requirements will be defined. For a given service, without such explicit requirement, the implementer can choose any of the following design:

• a single component derived from Smp::IService.
• a composite component and sub component with root composite derived from Smp::IService.
• a single component derived from Smp::IModel.
• a composite component and sub component with root composite derived from Smp::IModel.
• any other scheme of object composition as soon it can be inserted when into the simulator using the regular Smp::ISimulator interface.

The Smp::IModel or Smp::IService derivation shall be preferred for any component to be dynamically loaded through the library loading, factory and component instances creation features of the simulator (see Smp::ISimulator), in order to let the loaded feature being properly published and retrievable through the resolver service.

This feature shall let define aperiodic entry points activation. The following event kinds and scheduling policies shall be considered:

• a value is pushed to some of the entry point owner's input field.
• same than previous, but not only a value is pushed, but the new pushed value is not equal to the current value.
• the entry point may be scheduled now (current simulation time) or with a delay. Activation count and periodicity may be considered as well.
• when the entry point activation is requested by many events at the same simulation time, the entry point shall be scheduled only once. Said another way, the entry point should not be scheduled several times for the same simulation time.

The above policy may be refined as more formal requirement in future editions. The main motivation for such feature is to trigger computation only when relevant on external asynchronous and aperiodic stimulation. The SMP discrete event simulation kernel may then handle computation pipelines according to any on-demand strategy similar to the very common observer/observable patterns or publish/subscribe patterns.

The kernel library include an implementation for each of the mandatory SMP services:

• Logger
• Scheduler
• Resolver
• TimeKeeper

The services are created on the simulator construction to ensure availability at the earliest stages of the simulator build.

However those service shall be replaceable

, meaning a user may substitute anyone with its own implementation using the AddService method. To do so, this method dynamically checks the type of the service to add for each mandatory service type. When it matches a type, the simphonie's default service implementation is deleted and replaced by the new one. This makes the eventual configuration applied to the deleted service be lost. Each mandatory service type is checked in sequence, making a single object implementing many of the mandatory services be properly registered as the right instance for the many services it implements.

This way of doing (creating default services and replace later) has been selected because of the few early simulator building action that may need the availability of such service before any new one can be added. In most case this is without significant effect, since almost nothing is done before the first service addition and services should be added and more specifically published before any other kinds of components can be published.

The bundled resolver parses the pathes to be resolved according the following state diagram.

The scheduler / time keeper coordination relies on a specific event that is not defined in the SMP standard: Scheduler_PreEventExecute shall be registered in the event manager sometime during the simulator building phase. Then the follwing policy shall be applied to let the time keeper and scheduler fulfil each its own duty as defined in the SMP standard while being able to remain consistent with each other:

• the time keeper subscribes the Scheduler_PreEventExecute to trigger its own simulation time update process according the next scheduled event simulation time.
• the scheduler shall emit the Scheduler_PreEventExecute before running each scheduled entry point.

Any alternate scheduler or time keeper service implementation may be used as soon the Scheduler_PreEventExecute event is handled appling the policy defined above in this section.

According to the SMP standard, the simulator shall emit events when starting and stopping the simulation:

• on simulation start request, if the current state allows it:
• first SMP_LeaveStandby
• then SMP_EnterExecuting
• on simulation stop request, if current state allows it:
• first SMP_LeaveExecuting
• then SMP_EnterStandby

On start request, the simulator preforms the follwing actions:

• schedule a start entry point immediately (to be first to execute).
• emit the SMP_LeaveStandby event.
• emit the SMP_EnterExecuting event.
• wait for the start process completion.

The start entry point shall:

• save the current thread identifier. Since it is executed by the scheduler thread, this will be used on stop to detect the Hold method is called by a scheduled entry point, or externally.
• notify the Start caller thread to release it.

The Simulator's Hold method shall stop the simulation according its boolean argument:

• when true: stop shall be immediate, this as soon the currently executed scheduled entry point is completed.
• when false: stop shall be delayed when all entry point scheduled for the current simulation time are completed.

To do so, the simulator on Hold request, according the boolean argument, schedules its own stop processing entry point:

• immediatly (being the first entry point in the schedule list), when argument is true.
• at simulation time now (being the last for the current simulation time in the schedule list), when the Hold argument is false.

Once the stop entry point is scheduled, the Hold method shall wait until the stop entry point is completed (if not triggered by the scheduler thread itself), then it emits the SMP_EnterStandby event.

The stop processing entry point shall emit the SMP_LeaveExecuting event, then it shall release the Hold caller thread and the simulator shall then switch to standby state emitting the related event.

The scheduler shall:

• subscribe to the SMP_EnterExecuting event to start its own scheduling thread.
• subscribe to the SMP_LeaveExecuting event to change its running status and end itw own scheduling thread once the currently executing entry point is completed.

When an entry point execution is completed, each of its owner's output field Push method is invoked to forward the possibly updated data to each connected input field.