Target release | CANtactor v1 |
---|
Epic | Link to related Jira epic or feature |
---|
Document status | |
---|
Document owner | Jack Smith |
---|
Designer | |
---|
Developers | Lead developer |
---|
QA | Lead tester |
---|
|
Goals
- Provide a first pass PoC of a Contactor controlled by CAN bus
Background and strategic fit
This will be used by the Interlock Solution
Assumptions
- List the assumptions you have such as user, technical or other business assumptions. (e.g. users will primarily access this feature from a tablet).
Requirements / HW
# | Title | User Story | Importance | Notes |
---|
1 | CAN Bus enabled | Control of the node will be done over CAN-FD from the primary CANtroller of the interlock system. | Must Have | - Recommend also having side-band Digital I/O enabled on/off for testing
|
2 | uController in node | a small uC will generally be required in order to handle the CAN bus and the desired sensors. The uC should be relatively generic, such that if it needed to be changed it could be replaced with a different device. |
|
|
3 | Safety | The device needs to be safe, and should exceed basic safety ratings. | Critical for Safety | - All circuits carrying > 24V should be analyzed for safety. No Waivers.
- Creepage and Clearance requirements should specified and enforced.
- Reinforced insulation and Double Insulation should be considered.
- High-Pot testing should be performed before system is put in service
- Enclosure should require tool usage in order to access >24v circuits
- Warning Signs should be evident
|
4 | Voltage Measurement |
| Nice to Have / Future | - Voltage ADC should be fairly generic such that it can be replaced.
- Voltage ADC should be isolated from uC via magnetic or optical isolation
- Some uC may already include an ADC that can be used.
|
5 | Current Measurement | Being able to determine if the machine is on/off by current measurement will be useful. | Nice to Have / Future | - Current ADC should be fairly generic such that it can be replaced.
- Current ADC should be isolated from uC via magnetic or optical isolation
- Some uC may already include an ADC that can be used.
|
6 | Wiring | Much of the wiring in the device will handle high currents and high loads, and will need to survive for years.
| Critical for Safety | - Ensure that all wiring is properly insulated
- CAN Wiring will have twists (typically 40/meter for old CAN, TBD for CAN-FD)
|
7 | Indicators | A user should be able to see the status of the device easily when near it. | Must Have | - LED on input power indicating Powered / Unpowered
- LED on output power indicating Powered / Unpowered
- Consider LED on uC indicating node connected to CANtroller and blink for CAN activity vs node not connected to CANtroller.
|
8 | Termination | CAN bus needs termination | TBD | - Termination strategy is TBD
|
9 |
|
|
|
|
Requirements / SW
# | Title | User Story | Importance | Notes |
---|
1 | GitHub based S/W | Future developers and maintainers will want access to the code. | Critical | - Code must be maintained on DMS GitHub
|
2 | CAN Library | CAN library should ideally be common between the CANtroller and CANtacter | Nice to Have | - Differences in uC may make this difficult
|
3 | CAN Usage | The usage of the CAN bus should be very well defined and common between CANtroller and CANtacter | Must Have | - Keep the same RFC / APR for the usage of the CAN bus
|
4 | Node ID | Each node should have a unique ID and should be able to | Must Have |
|
5 | Prevent_Off_when_running | Cutting power to a high powered device while it is in operation can be damaging. | Must Have | - CANtactor can Deny a CANtroller request to turn off
- TBD: should CANtactor shut down when safe, or should it wait for continued requests from CANtroller?
|
6 | 11bit vs 29bit addressing? | TBD |
|
|
7 |
|
| TBD |
|
User interaction and design
User interaction and design
Include any mockups, diagrams or visual designs relating to these requirements.
Questions
Below is a list of questions to be addressed as a result of this requirements document:
Question | Outcome |
---|
(e.g. How we make users more aware of this feature?) | Communicate the decision reached |
Not Doing
- List the features discussed which are out of scope or might be revisited in a later release.