Readers Note:

This is currently on working prototype 3,

• Prototype 1 - using ESP8266 creating a Webserver interfacing with a PIR sensor to update value of nearest object.

• Prototype 2 - using an ESP32 creating a Webserver with latch switch to update value of door open/closed.

GitHub link for Prototype 1 & 2.

Project Scope:

Within Scope:

Design an implement two Subsystems. An Embedded system and a Desktop System.

Each system must be able to work independently to the other.

Each must be compatible with upgrade paths for future platforms.

Outside of Scope:

Designing for full production scales.

Any legal implementation of the design, manufacture or usage of product.

Design an embedded system:

• Small form factor (20 cm x 20cm x 10cm maximum). -IoT sector is all about using smart but compact devices able to be hidden away or unobtrusive.

• BoM Cost to be kept within £50 per unit. Devices need to be affordable as seen as non-vital goods to many companies.

• 5 day usage between charging. Users won't use a product which requires constant removal and charging as the upkeep to benefit ratio would decrease.

• Life cycle expected to last multiple years. Allowance for guarantees and buyer confidence whilst also leaving the option of subscription based services for additional revenue.

Desktop Subsystem:

• Platform Compatible with Windows,Linux,Mac. Allows for maximum coverage of user group.

• Non-Blocking Design allowing as background task. Cannot impede workflow or productivity as product is an aid.

Scaling

Initial System Design

Prerequisite Design Requirements

Environmental Conditions:

Operating Temperature range:

• -40 to 125 Degrees Celsius for ESP32 Module. (1)

• -10 to 60 Degrees Celsius for LiPo Battery. (2)

• -40 to 85 Degrees Celsius for Li Battery Charger.(3)

• Therefore critical operating temperature range of -10 to 60 Degrees.

Storage temperature range:

• -40 to 150 Degrees Celsius for ESP32 Module (4).

• -10 to 35 Degrees Celsius for LiPo Battery. (2).

Storage humidity range:

• 192 Hours at 60% humidity maximum, (MSL 3, J-STD-020) for ESP32 Module. (5)

• Working life at below 75% humidity maximum for LiPo Battery.

ESD:

ESP32 Module:

• CDM +- 500V [JESD22-C101]

• HBM +- 1500V [JESD22-A114]

• Air discharge: 6000V

• Contact discharge 4000V.

LiPo Battery:

• Touch discharge: 20000V

• Air discharge: 20000V

Maximum Ratings:

Esp32 Module:

• Vin Pins -0.3 to 3.7V

• Iout 0 - 1200 mA

LiPo Battery:

• Vin 4.325V (Overcharge Protection).

• Iout 0-2000 mA.

Li Battery Charger:

• Vin -0.3-8V

• Iout 0 - 1050 mA

Recommended Operation Ratings:

Esp32 Module:

• Vin 3.3V

• Ioh 40mA (per pin).

LiPo Battery:

• Vout 3.7V

• Vin 4.2V

• Iout 2000mA

Li Battery Charger:

• Vcc 5V

• Icc 1000 mA

Circuits to be soldered within an ESD safe environment.

Circuits to be placed within an enclosure offering partial protection.

Product is not for operation within corrosive environments. Potting is not required.

Product is expected for installation indoors.

Compliance Requirement.

Which IP and ISO to comply with.

JEDEC standards.

ISO9001 Project standards.

IEC Standards.

IP67

BoM- Bill of materials.

Rough Cost for full product and step up design costings

Cost(per unit) - Component.

£1.46 - Esp32 Module.

£0.23 - Lithium Battery Charger.

£2.30 - LiPo 2000 MaH Battery.

£0.30 - PCB for module.

£0.70 - Plastic Enclosure 80x60x30 mm.

£0.65 - STSP micro switch.

Unit Price - £5.68 (excluding VAT).

BoM expected to reduce as manufacture Volume increases.

The BoM cost would be required to be within £10 margin.

Expected Production Volume

Due to Niche of Prouct, batch production would be most efficient, with high volume optimisation only required in late stage of product success.

Optimisation over to entirely machine soldered components is possible with automated inspection but not financially viable as the design is fairly simplistic. Design of automated testing of hardware and component laying machine design is predicted to be a net loss at early design stage.

Product Availability

Product requirement is predicted to be short term demand driven. Alternative component sourcing requirements are not applicable as no assertions of continued product production after initial batches.

Warranty

Product is expected only to be provided with minimum warranty with a replace rather than repair clause for the duration of the warranty.

Main Features

Hardware

• Recharging using Standard MicroUSB 5 V Cable.

• Device operation of 5 days without recharge.

• Device have 802.11 Wifi connectivitiy.

• Device should have sleep function.

• Device should be able to recharge in under 2 Hours.

• Device should operate within reasonable noise safety requirements.

• Device to be enclosed in enclosure no larger than 100x80x50 mm

Firmware

• Bare Metal OS or RTOS.

• Operational Flow of Access Point creation to allow for User to save WiFi ssid and password into Embedded system memory.

• Power saving mode usage and limited communication protocol usage.

• Allow for OTA updates to Firmware via WiFi stack, without allowing access to saved ssid and passwords.

• Communication Protocols: UART for debugging and uploading of code, MQTT for message exchange.

Software

Process Requirements:

Version control:

• Use of Git to maintain a systematic approach,

• Main branch containing iterative roll out of each working deployment.

• Development branch merging in new features, with work completed in development branch.

• README Document containing each version, highlighting changes and referencing any Git Issues solved by the version.

Documentation Tooling:

• Doxygen used to document written source code.

• Fully commented code from build scripts to unit tests.

CI/CD:

• Continuous integration completed by Git(hub/lab) Actions to incorporate various testing workflows. Including use of Make Integration on main branch commit.

• Test Automation to include Unit test coverage.

Issue Tracking:

• Completed via Git inbuilt tracking.

Hardware in loop:

• Testing to be completed at each new embedded subsystem version.

Testing:

• Each method should be unit tested by predictable outcomes.

• Test modules should be within separate modules where possible.

• For bare metal software tests, hardware should be tested prior as well as in collaboration with software.

• Finished Desktop subsystem builds should be tested across all usage platforms (Mac,Windows,Linux).

• Static Code Analysis is to be used during the testing process at specific versions.

Software - High Level Code Execution Plan

Software - High Level Code Execution Plan