Features
tangentaudio edited this page Jan 31, 2017
·
7 revisions
- Robust, reliable hardware & firmware
- Tolerant of electrically noisy industrial environment - EMI & RFI
- Robust error handling, timeouts, etc. in firmware
- Tolerant to power loss without data corruption (battery backed?)
- Tolerant to network, server, and other infrastructure outages
- Pain-point from legacy system which had a dependency on Internet connectivity to a Google Apps server
- Do not depend on live backend connection for authorizations - cache ACL locally and use it
- Do not depend on live backend connection for logging - cache locally on NV storage and upload when connection available
- Fast from cold boot to authorization - 15 seconds or better
- Not all equipment powered up full-time, e.g. welders
- Configurable time-out scheme based on tool activity (where applicable)
- Not reasonable to require RFID for every time a tool is powered up
- Unlocking tool starts a countdown timer of configurable length
- Whenever tool is in use, countdown timer resets
- Audible and visual indications when timer is near running out and has run out
- Informative user experience
- Whenever possible favor giving user useful information at the access control node
- e.g. LCD with words "Training Required" better than LED indicating "access denied"
- Prominent display of name of who has tool activated
- Potential display of last user(s) to have used the tool - shaming concerns?
- OTA Firmware Updates
- Must be secure and robust
- Must account for customized firmware that will be running on various nodes
- Tool Needs Attention
- Simple mechanism for tool users to report issues back to Resource Manager, right from the access control nodes
- May be binary, or may allow user to select from configurable canned status messages indicating why tool needs attention (e.g. "damaged," "low on consumables," etc.)
- Remote lockout feature
- Combination of backend and access control node features
- Allow Resource Managers to disable a tool via the backend web interface
- Allows Resource Managers to "close the loop" on the tool attention required reports
- Tool usage reporting
- Access control nodes collect and report who has used tools and for how long
- Backend collects usage data and provide it to Resource Managers via web interface
- Real-time tool status display for members to view via web (idle/active/disabled)
- More enhanced user experience
- When users denied access to a tool, emails/slack messages/etc. could be sent to user informing them of training classes, links to wiki, etc., all via the backend
- Consider embedding scripting language for application logic
- Base platform firmware in C
- Application-specific logic in scripting language, scripts stored on SD card/Flash
- May allow for single firmware image for all nodes, with customized script for each tool/equipment
- Allows non-embedded programmers to make logic changes or adapt to a tool without compromising stability / integrity of the platform code
- See MicroPython ESP32 Port