Embedded File Systems
File systems for embedded devices control how data is stored and retrieved on a data storage media. There are many different kinds of file systems. Each one has different structure and logic and different properties of speed, flexibility, security, size and more. File systems for embedded devices can be used on many different kinds of storage devices. File systems impact the read and write performance of the physical storage, the integrity of the data stored, flash endurance or the lifetime of the memory hardware, and data and storage interoperability. For an embedded device, file systems need to be power, fail-safe. All our solutions have patented methods to ensure data, volume, and metadata integrity, plus they work across a wide variety of operating systems.
Reliance Assure™ helps you achieve your compliance and reliability goals for developing high-quality, safe systems. With Reliance Assure, we aim to help you reduce the time for certification of your embedded systems.
Reliance EdgeNAND™ is a fully integrated flash file system designed to capture and preserve data on SPI NAND and other software-managed raw NAND flash media. With an integrated flash translation layer that protects your critical system and user data from corruption, Reliance EdgeNAND is specifically designed for maximum reliability – overcoming power losses and keeping your data safe.
Reliance Edge™ is the only file system that offers power fail-safe reliability and deterministic behavior required by today’s autonomous systems. Ultra-compact (4 KB of RAM, 12 KB of code), configurable and conforms to MISRA C:2012.
Reliance NitroTM is a transactional file system created specifically for embedded devices where power loss may occur, protecting critical system and user data from corruption. It ensures rock-solid data reliability while providing the performance needed to create an optimal user experience.
How Logic Technology helps you manage your data
This is the age of analytics and artificial intelligence. Data is changing the world we live in and the way we work. It is unimaginable not to have access to data for a week, a day or even for an hour; most of the decisions we make during a day rely on (transformed) data coming from various sources. It is very likely that the products you design collect, process, analyse and transform data either to perform control functions, present information or store and archive data for future reference. Aspects like speed of data processing, reliability and security will undoubtedly be of importance for the acceptance of your product and application by your customer. In talking to hardware and software developers we frequently hear that the challenges for a new product design often are related to uncertainty on the future expansion of data, throughput, storage and storage device reliability.
A good data management strategy starts at the foundation of your product: the storage device or memory. If you use an SSD or memory card, it is of course industrial grade. Its big advantage is that it’s durable, exchangeable and easy to use from an application viewpoint. If you don’t have the luxury of board space or need to reduce cost, your product most likely will use some sort of raw flash memory soldered to the board. For the firmware developer a bit more challenging since now the need arises for a block device driver and flash translation layer to talk to the memory device. In the likelihood that you are using NAND devices, bad block management needs to be implemented too. Fortunately, most flash memory manufacturers provide basic block drivers, and there is of course a pool of open source drivers available.
But now, let’s get back to your original concerns: how do you safeguard that the data on your memory devices remains intact over time, after unscheduled system events, when throughput increases and memory begins to fail? How do you secure the data on the device? In the case of raw NAND, a block driver with atomic writes safeguards that data is committed only when it is truthfully written to the media. The driver needs to have a mechanism of wear levelling, to assure that the expected lifetime of the memory device is not cut short. And if memory starts to fail, its bad block management should handle it swiftly. In case of a memory device with integrated controller, you would not directly be concerned about these issues.
For both raw and controlled memory strategies, trouble comes from the applications accessing the media, by means of a filesystem infrastructure. This is where performance, security and system recovery time come to play. Not all filesystems perform well on all these aspects, and in many cases they are overlooked when the selection of the proper embedded (real time) operating system is at hand. However, there are reliable embedded filesystems available with drop in RTOS support that match all of these criteria and still offer flexibility for future application and data expansion.