INTL
Freelancer
전문가
외주
원격 가능
Electronics Firmware Creation
예산
30~250 CAD
예상 기간
1~3개월
난이도
전문가
기술 스택
Embedded C/C++
Microcontroller Programming
Real-time Embedded Systems
Finite State Machine (FSM)
Hardware Interfacing
Sensor Integration
Actuator Control
Watchdog Timer
Non-volatile Memory (NVM) Logging
AI 분석 요약
이 프로젝트는 차량 내 휴대폰 사용을 물리적으로 제한하는 'Box Capsule' 장치를 위한 임베디드 펌웨어를 개발하는 것입니다. 실시간 센서 입력과 결정론적 상태 기반 제어 로직을 통해 잠금 메커니즘을 제어하며, 안전성, 신뢰성, 예측 가능한 동작을 최우선으로 합니다. 정교한 상태 머신 설계와 모듈화된 아키텍처 구현이 요구됩니다.
프로젝트 원문 설명
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
Freelancer에서 원본 확인
원본 보기