This form is intended to assist in capturing the requirements for new Open Source Embedded Systems Projects,
its scope & implementation can be adapted to suit projects of varying complexity.
The project brief should contain an outline of the proposed project, with enough detail to derive a comprehensive list of requirements. The format, layout and information provided can be tailored to project complexity
PCB required to host DC-DC converters, to convert 24V DC power supply into operating voltages for ISO Experimental containers. The containers house 4 experiments, each requires 12v for motor power, and 5v for raspberry pi via USB. Each USB 5v channel requires a power switch that can be actuated remotely.
Total current draw for 12v & 5v bus should be monitored via a microcontroller, with a interface allowing control over power switches on the board. Additional 5v & 12v power channel is required for future proofing, additional control infrastructure etc.
LED indication of correct voltage for 24v, 12v & 5v bus. Cooling should be provided for DC/DC Converters. Estimated power requirements set out in sub-system specification below.
Any features or functions that are optional should be stated here
- Report Status & current usage for sustainabilty and maintainance purposes.
- Individual remote control of channel power.
- Use only connection types that can be operated with one hand. i.e. avoid screw terminals.
Specific requirements for subsystems should be documented at this stage
a. steady power usage of 20W 1.7A at 12V (Maxxon AMax 32 236668 Graphite brushes, 20 Watt)[Estimated value, may change in future iterations]
b. peak power usage of 69W 5.7A at 12V (when motor stalled) [Estimated value, may change in future iterations]
c. 5V power for the Raspberry pis, typically 2.5A per Raspberry Pi; four raspberry pi connections, 1 connection for power to microcontroller monitoring chip.
These specifications are going to be valid for most projects developed using this framework
- Circuit should be protected from reverse supply voltages.
- Circuit should be fuse protected
- 5v bus should be protected from over voltage conditions.
What parameters of the design should be minimised/maximised?
Space for discussion and weighing up of features that may or may not be required
What quality assurances or requirements, if any, need to be established?
Any Extra Notes? Software Reqirements: JSON commands/interaction with microcontroller -> actuating commands & reporting Status. reporting of status 1 per second. Minimum include current for 5v bus & 12v bus, time since last reset - as integer Not float. (keep track of number of times millis() rollsover) value good for 10 years.
443 TCP
Whenever voltage out of spec log on controller, send message via json, LIMIT MESSAGE RATE. query data remotly, how many time tripped, last time tripped. way to reset count?
Break in auto detect line to or gates so can be easily disabled.
DC power Supplies fault output. use for visual indication lEDs & report via JSON.
The project brief may also contain information on currently available similar products and a brief description of the features they lack and a quick review of whether they can fullfill the aims of the project.
This section should contain a numbered list of all the specific high level requirements that can be gathered from the project brief, or from the client directly.
High Level Requirements capture the intent and function of a system, without going into specifics of how these will be achieved or any specific implementations. I.E. They take a Black Box approach
- Client Needs
- Features & Functionality
- Interfaces
- Performance
- Quality Attributes
- Design Constraints
- Regulations
- Safety & Security
- System
- Specific - Document a single feature or function requirement at a time.
- Quantifyable - Provide quantifyable parameters, boundary limits of operation and/or design tolerences, rather than open ended specifications where possible.
- Self Contained - Do not rely on assumptions to deliver information, as different engineers will make different assumptions, which may cause conflicts
- Traceable - Assign each requirement an ID number, this will be used to trace any design decisions through the development process.
Good requirements are the foundation for successful development of a project, as it allows design decisions to be traced through the development process. it also provides the information required to undertake successful Verification & Validation1.
HL.1. DC/DC converters must be able to provide continuous current draw of 6.7A at 12V ~(80W) for motor power, from supplied 24v input.
HL.2. DC/DC converters must be able to provide peak current draw of 12A at 12V ~(144W) for motor power, from supplied 24v input, in case of stall condition.2
HL.3. USB power must be able to provide total of 12.5A @ 5v ~(62.5W), from supplied 24v input.
HL.4. Each USB channel will have the ability to remotely disable and re-enable power.
HL.5. Voltage & Current monitoring of 12v bus, accessable remotely.
HL.6. Current monitoring of 5v bus, accessable remotely
HL.7. Board must have push-fit or bayonet connectors for motors & offboard hardware.
HL.8. Power Board will have 5 * 12v outputs from 12v Bus.
HL.9. Power Board will have 5 * 5v outputs from 5v Bus.
HL.10. Power board will be protected from reversed supply voltages
HL.11. Power Board will be protected from over-current conditions
HL.12. PCB must have same footprint & mounting screwholes as V1, to aid in assembly
HL.13. 5v bus will be protected from over-voltage condition.
HL.14. Each power bus will display visual (LED) indication of correct operation or fault conditions (over/under voltage)
When to review?
High level requirements should undertake a review process, Validation, to ensure they meet the clients needs, before any further development takes place.