Required stack
필요 기술
Embedded C/C++Microcontroller ProgrammingReal-time Embedded SystemsFinite State Machine (FSM)Hardware InterfacingSensor IntegrationActuator ControlWatchdog TimerNon-volatile Memory (NVM) Logging
Project brief
프로젝트 내용
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
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