This guide lays out the recommended order of work for building a new APIC-based system, from defining its models down to acceptance testing.
1. Define the Models and States for Each Model
A Model is a logical unit that represents a subsystem or functional domain — it runs at a configured rate, owns one or more state controllers, and is responsible for its own state transitions, stream processing, and block generation. Start by identifying the models your system needs and, for each one, the state controllers and states it will own.
Models can depend on other models — declare those dependencies explicitly (via configuration or the scheduler) so the scheduler orders execution correctly and data produced by one model reaches its dependents deterministically.
2. Define the CoreEngine Interfaces
Define how data moves both inside and outside the CoreEngine:
- Internal — between models, via shared LRU blocks/elements in the ICD.
- External — between the CoreEngine and external devices, defined in streams.json as drivers and streams.
3. Define Each Model's Logic from the FRS
Extract each model's behavior directly from the Functional Requirements Specification (FRS) document, so the model's implementation traces back to a documented requirement rather than an assumption.
4. Define State Logic and Switching Conditions
For each state, define its logic and the conditions under which it switches to another state. Keep each state's responsibility small and deterministic, and make transitions explicit rather than implicit.
5. (Optional) Build the OGI Application
If the system needs an operator interface, create an OGI application. Use a graphical designer to build the UI in AXAML (cross-platform), XAML (Windows), or HTML (cross-platform), then connect the UI to the CoreEngine — see the OGI development guide for how to.
6. Define Unit Tests for Each Model
Write unit tests per model using Test Plan CSV files, so each model's behavior is verified in isolation before it's integrated with the rest of the system.
7. Define ATP Tests for the Whole System
Finally, define Acceptance Test Procedure (ATP) tests for the system as a whole, again using Test Plan CSV files, to validate end-to-end behavior against the system's requirements.