Skip to content

Development plan

Info

This document is still a draft and is missing sections.

The development plan is provided as a guidance on how the project is developed. It's guiding, not prescriptive.

Change management

Changes are categorized into which type of change it concerns:

  • A change request changes how the system is intended to function. This can be adding or changing a requirement such that previous implementations are no longer fulfilling specifications, changing the architecture of the system, etc.
  • A defect correction adjust documenation, source code or other configuration item such that it is correct. Correct in this case can be adhering to specification, fixing typo, clarifications or other changes that does not change the intention of the system.
  • An engineering change is a change to the system that does not correct a defect or changes the functionality of the system. This can be adding tests, updating dependencies, etc.
  • A release request is a special kind of change request, where the system is relased for use. See Release process and versioning.

Changes are registerd in Gitlab by creating a new issue and using the appopriate template.

Implementation is done by opening a MR to main and fill out the appropriate template.

Configuration management

All items placed in Gitlab is configuration items. These cannot be changed without following change management. (See above)

Documentation of the project is published at Gitlab pages.

For valid configuration items, see Release process and versioning below.

File organization

The project uses a mono-repo structure, meaning everything is put in one repository. The structure is as follows:

  • aqla-fw: Source code for firmware
  • aqla-hw: KiCAD projects for hardware
  • docs: Project documentation not part of the design files

Software file organization

cargo is used to build the software.

To enable running unit tests without compiling to specific hardware, there are two workspaces;

  • outer, located at aqla-fw contains generic code that can build on any host. Any non-hardware specific code should be placed in an approriate crate at the outer workspace.
  • inner, located at aqla-fw/cross contains code that needs to be cross-compiled to target. Cross-compiling is controlled by aqla-fw/cross/.cargo/config.toml.

(Note that there is nothing that define the names; they are just Cargo.toml files located at these directories)

Verification

Info

This section is still a draft. It should include details regarding:

  • Unit testing
  • HIL testing
  • System testing

Release process and versioning

The release process is as follows:

  1. Create a Release request. See Change management
  2. Open a MR to the relase branch.
  3. Fill out the release template, performing activites as necessary.
  4. Add the release notes to source control.
  5. If all activities have been performed adequately, merge the changes to release.

Info

This section is still a draft. It should detail:

  • What actions are needed for release, and how to track them?
  • Versioning scheme used.