|
|
|
# FRMS
|
|
|
|
ForeLight Reactor Management System
|
|
|
|
|
|
|
|
Time to get to business
|
|
|
|
|
|
|
|
|
|
|
|
## Main design principles
|
|
|
|
- Flexible
|
|
|
|
- Reliable
|
|
|
|
- Scalable
|
|
|
|
|
|
|
|
Those principles guide our design choices
|
|
|
|
|
|
|
|
### Flexible
|
|
|
|
- System should support any reactor config
|
|
|
|
- should be able to change sub packages in isolation
|
|
|
|
- portability of packages i.e. can swap databases or sub in testing packages for memory based storage
|
|
|
|
|
|
|
|
### Reliable
|
|
|
|
- should support any # of reactors failing (including network related failures)
|
|
|
|
- should provide log and database correctness via atomic commits
|
|
|
|
- automatic log recovery and reactor functioning despite sub-system or network failures
|
|
|
|
- 100% uptime and seamless updates **goal**
|
|
|
|
|
|
|
|
### Scalable
|
|
|
|
- Add and use sensor packages at will
|
|
|
|
- Group reactors logically regardless of physical location
|
|
|
|
- Scale infrastructure to efficiently support any # of reactors
|
|
|
|
|
|
|
|
### TODO
|
|
|
|
|
|
|
|
- [ ] Convert reactor architecture to Rust
|
|
|
|
- [ ] build I2C rust interface
|
|
|
|
- [ ] connect to base gRPC via rust
|
|
|
|
- [ ] automate builds
|
|
|
|
- [ ] fix docker automation
|
|
|
|
- [ ] Add a test suite for both go and rust implementations
|
|
|
|
|
|
|
|
|
|
|
|
|