Overview¶

• In Sen, you write packages. Packages contain your functionality in the form of classes that can be instantiated to create objects. A Sen object is a C++ object plus everything the code generator gives it: serialization, introspection, and a place on a bus.

• By writing config files, you tell Sen which packages to load and which objects to create. The grouping of objects that run in a thread and serve some specific purpose is called component.

• Components can be instantiated wherever you like (same process, same computer, other computers) and Sen makes this transparent to your code, though not to its timing and failure modes: see what distance costs. You achieve this by publishing objects to buses. Sen sessions are namespaces for buses.

• Time can be virtualized. Sen can run your code in real time or stepped mode (slower or faster than real time, you choose).

• You can define your types and classes using a little language called STL, and it can also be done using standard HLA FOMs.

• Sen ships tools for interacting with a running system, testing it, scripting it, and building your own.

Those are the moving parts. The words Sen uses for them:

• Classes define the interface of objects.

• Objects encapsulate state (properties) and behavior (your code).

• Packages are libraries of classes.

• Components run your code by importing packages and instantiating objects.

• Systems are a collection of components that are organized for a common purpose.

Where to go from here¶

Start with the ideas. Mental model is the shortest route to thinking about Sen the way Sen works. Main concepts goes over objects, components, buses and the quality-of-service choices in more detail. Execution model explains what happens in a single cycle, and Workflow describes how a project usually grows.

Then the language you write interfaces in. STL is the tour, and STL grammar is the exact syntax when you need to look something up. If your interfaces come from somewhere else, HLA FOMs covers the simulation standards, and Compatibility and conversions explains what happens when two sides disagree about a type. Sen Query Language is how you filter objects.

Then running and building things. The configuration file is the reference for the YAML that sen run takes, and Command line documents the commands themselves. CMake documents the build functions your own package will call.

Code generation covers what Sen writes from your model, how to ask for it from a build or from the command line, and what surprises people about each generator.

Crash reports is what a process leaves behind when it dies, where the files go and how to read them.

The libraries, if you are working against the C++ API directly: core for the base types, kernel for the runtime, util for the helpers, db for recorded data and gen for the code generator. The database also has Python bindings for reading recordings.

When the network does not behave, the FAQ covers why Sen uses multicast, how to force TCP, how to discover remote kernels without multicast at all, and the user limits WSL2 imposes.