Electronics Firmware Creation
Budget: $30 – $250 CAD
PROJECT DESCRIPTION
Package E – Embedded Firmware Development
Project: Box Capsule
1. PROJECT OVERVIEW
Box Capsule is a vehicle-mounted hardware device designed to physically restrict access to a mobile phone while driving.
The system operates as a standalone embedded device. Its purpose is to reduce driver distraction by controlling physical access to the phone based on real-world conditions such as motion and user interaction.
This is not an app-based solution. All critical functionality must be executed locally on the device.
2. SYSTEM OBJECTIVE
The firmware must control a locking mechanism that:
* allows the user to insert a phone
* detects lid status (open/closed)
* detects motion or driving condition
* locks the phone when required
* prevents access while driving
* allows safe unlocking when conditions permit
The system must prioritize safety, reliability, and deterministic behavior.
3. CORE FUNCTIONAL REQUIREMENTS
The firmware must implement:
* real-time input monitoring
* deterministic state-based control logic
* actuator control (lock/unlock)
* emergency override handling
* fault detection and safe fallback behavior
The system must behave predictably under all conditions.
4. SYSTEM ARCHITECTURE
The firmware must be structured into clear modules:
* system initialization
* sensor/input manager
* state machine controller
* latch/actuator control
* fault manager
* watchdog system
* diagnostics interface
* event logging system
Each module must be independent and maintainable.
5. STATE MACHINE REQUIREMENT
A formal finite state machine is required.
Typical states include:
* BOOT
* IDLE (no phone or lid open)
* READY (phone inserted, lid closed, no motion)
* LOCKED (during motion)
* UNLOCK_READY (safe to unlock)
* EMERGENCY_RELEASE
* FAULT
All transitions must be clearly defined and documented.
6. INPUTS AND OUTPUTS
The firmware must support the following logical signals:
Inputs:
* phone presence detection
* lid open/close detection
* motion detection
* emergency override input
Outputs:
* lock actuator control
* status indication (LED or equivalent)
Exact pin mapping will be defined separately.
7. SAFETY AND RELIABILITY
The system must:
* operate fully offline
* never depend on external connectivity
* include watchdog protection
* handle unexpected resets safely
* ensure fail-safe behavior on fault
Safety-critical functions must always have priority over secondary features.
8. EVENT LOGGING (FOR FUTURE EXPANSION)
The firmware must include a basic event logging capability.
This will be used in future versions for compliance and reporting.
Events may include:
* lock/unlock actions
* motion detection
* user interactions
* fault conditions
Logging must:
* use non-volatile memory
* not interfere with real-time control
* follow a simple structured format
9. FUTURE COMPATIBILITY (IMPORTANT)
The firmware must be designed so that future features can be added, including:
* data export
* external communication (BLE or similar)
* compliance reporting systems
* integration with external platforms
However:
Core lock/unlock behavior must NEVER depend on these features.
10. DEVELOPMENT REQUIREMENTS
The developer must:
* use structured, readable code
* follow embedded best practices
* document all modules and logic
* provide a clear architecture overview
11. DELIVERABLES
Required deliverables:
* full firmware source code
* state machine diagram
* module architecture description
* input/output mapping
* build and flashing instructions
* test procedure documentation
12. EXPECTATIONS
This is a safety-related embedded system.
The focus is on:
* robustness
* simplicity
* reliability
Overengineering, unnecessary complexity, or cloud-dependent logic is not acceptable.
END OF DOCUMENT
Package E – Embedded Firmware Development
Project: Box Capsule
1. PROJECT OVERVIEW
Box Capsule is a vehicle-mounted hardware device designed to physically restrict access to a mobile phone while driving.
The system operates as a standalone embedded device. Its purpose is to reduce driver distraction by controlling physical access to the phone based on real-world conditions such as motion and user interaction.
This is not an app-based solution. All critical functionality must be executed locally on the device.
2. SYSTEM OBJECTIVE
The firmware must control a locking mechanism that:
* allows the user to insert a phone
* detects lid status (open/closed)
* detects motion or driving condition
* locks the phone when required
* prevents access while driving
* allows safe unlocking when conditions permit
The system must prioritize safety, reliability, and deterministic behavior.
3. CORE FUNCTIONAL REQUIREMENTS
The firmware must implement:
* real-time input monitoring
* deterministic state-based control logic
* actuator control (lock/unlock)
* emergency override handling
* fault detection and safe fallback behavior
The system must behave predictably under all conditions.
4. SYSTEM ARCHITECTURE
The firmware must be structured into clear modules:
* system initialization
* sensor/input manager
* state machine controller
* latch/actuator control
* fault manager
* watchdog system
* diagnostics interface
* event logging system
Each module must be independent and maintainable.
5. STATE MACHINE REQUIREMENT
A formal finite state machine is required.
Typical states include:
* BOOT
* IDLE (no phone or lid open)
* READY (phone inserted, lid closed, no motion)
* LOCKED (during motion)
* UNLOCK_READY (safe to unlock)
* EMERGENCY_RELEASE
* FAULT
All transitions must be clearly defined and documented.
6. INPUTS AND OUTPUTS
The firmware must support the following logical signals:
Inputs:
* phone presence detection
* lid open/close detection
* motion detection
* emergency override input
Outputs:
* lock actuator control
* status indication (LED or equivalent)
Exact pin mapping will be defined separately.
7. SAFETY AND RELIABILITY
The system must:
* operate fully offline
* never depend on external connectivity
* include watchdog protection
* handle unexpected resets safely
* ensure fail-safe behavior on fault
Safety-critical functions must always have priority over secondary features.
8. EVENT LOGGING (FOR FUTURE EXPANSION)
The firmware must include a basic event logging capability.
This will be used in future versions for compliance and reporting.
Events may include:
* lock/unlock actions
* motion detection
* user interactions
* fault conditions
Logging must:
* use non-volatile memory
* not interfere with real-time control
* follow a simple structured format
9. FUTURE COMPATIBILITY (IMPORTANT)
The firmware must be designed so that future features can be added, including:
* data export
* external communication (BLE or similar)
* compliance reporting systems
* integration with external platforms
However:
Core lock/unlock behavior must NEVER depend on these features.
10. DEVELOPMENT REQUIREMENTS
The developer must:
* use structured, readable code
* follow embedded best practices
* document all modules and logic
* provide a clear architecture overview
11. DELIVERABLES
Required deliverables:
* full firmware source code
* state machine diagram
* module architecture description
* input/output mapping
* build and flashing instructions
* test procedure documentation
12. EXPECTATIONS
This is a safety-related embedded system.
The focus is on:
* robustness
* simplicity
* reliability
Overengineering, unnecessary complexity, or cloud-dependent logic is not acceptable.
END OF DOCUMENT