# Why RustiQ IoT ? There are a couple of existing iot stack out there, so why building a new stack ? The market seems full of new stacks, taking advantage of large frameworks. The usage of containers and virtualisation seems a solution to separate application from the plateform and ease the building stack. ## Development Complexity in Embedded Projects Embedded projects typically involve managing multiple layers of complexity: - **Development Environments**: Multiple toolchains, cross-compilers, and SDKs for different target platforms - **Testing Challenges**: - Hardware-in-the-loop testing - Real-time behavior validation - Resource constraint verification - Environmental condition testing - Power consumption optimization - **Technology Stack**: - Bootloader configuration - Operating system customization - Device drivers - Communication protocols (I2C, SPI, UART, etc.) - Networking stack - Application layer - **Quality Assurance**: - Firmware validation - Over-the-air update testing - Long-term reliability testing - Security vulnerability assessment RustiQ IOT helps manage this complexity by providing a structured framework and tools that handle many of these aspects, allowing developers to focus on their application-specific requirements. ## Design and implementation choices RustiQ Iot made difference choices in implementation : - Stay as close as possible to the RAW OS, and interfaces - Linux and OS are very robust software and let manage easily application crash, restart as well as communication channels (IPC/Sockets .. ) - Minimizing the requierment of hardware in the service layer (defining simple and flexible interfaces), let simplify the development of large applications and ease module updates. - Ease the cross compilation level - using only process and command line, cross compilation is easy and speedup the development and testing of the application - Separate hardware specific functionnalities into hi level services, - In the stack the factory_service plugin offers the hardware related services associated to a plateform and OS, for example (wifi, (station / access point), powermanagement) The main benefits of this approach is to be able to have module that can be easily ported to other plateforms, but also tested on a development station. Implementing **Service Mock** on development stage is quite convenient for testing dynamic behaviour. ## Key Features Table | Feature Category | Key Features | | --------------------- | ------------------------------------------------------------ | | **Hardware** | Linux based Socs, Flash, additional microcontrollers ,Peripherals | | **Connectivity** | Wi-Fi, Bluetooth, Ethernet, (LoRa, CAN, I2C throught additional modules) | | **Software Stack** | Linux, Embedded Linux, Middleware | | **Security** | Secure boot, Encryption, Authentication, OTA | | **Development Tools** | GCC, Clang, Rust | | **Performance** | Power optimization, Real-time tuning, Latency | | **Compliance** | JSON, XMLRpc | | **Use Cases** | IoT, Automotive, Industrial, Consumer Devices |