Developers are encouraged to experiment with different software architectures in Lorien. This is relatively easy to do thanks to its component-based design and the relatively coarse-granularity of components (typical systems consist of 10 to 15 components). To help with this process we describe some of the common architectures below - but try not to see these as "standard".
In the following, components shaded in purple contain platform-specific elements while those in blue are platform-independent.
Illustrated above, this architecture contains all components needed to receive files (e.g. components) over the network. If "evolution scripts" are received then the software changes that they specify are enacted at the node.
The architectural roles here interact as follows:
CPU: Controls the microcontroller including its speed and sleep status. This component has no dependencies.
Scheduler: This is Lorien's default task scheduler which enqueues and executes tasks in FIFO order. It uses the CPU component to automatically put the CPU into its low-power sleep mode whenever there is no work to do.
Radio: The radio driver; it handles interrupts indicating data arrival, buffers data, and registers tasks to deliver that buffered data to interested components. Other components can register interest in receiving data on a given virtual port.
MAC: The MAC protocol (e.g. CSMA or LPL). It exports the same provided interface as the radio driver, allowing other components to use MAC or Radio directly without changing their code. MAC connects to the Radio driver's interfaces to receive incoming data and send data as requested. When data is received by MAC from Radio it is re-buffered in MAC and a new task registered with the scheduler in which to deliver that data to interested components. The LPL MAC protocol also duty cycles radio power using the radio driver's hardware control interface, with timing for duty cycling sourced from the Timer component. MAC protocols may also use the random number generator component to source random backoff periods in the face of channel contention.
Timer: General timer service; it handles interrupts from a hardware timer and registers tasks to fire those timeouts in their requesting components. Lorien has timers that operate at various precisions. The most commonly used precision is the 32ms timer whose smallest possible timeout is 32ms.
Random: A source of random (or pseudo-random) numbers.
FED16: Forward Error Detection module, such as CRC; the "16" indicates provision of 16-bit (2-byte) FED coding.
XFS: External flash memory chip block driver. Used to store files that arrive over the network or other files generated by applications (see MassStorage).
ROMFS: MCU-internal flash memory (program memory/ROM). Used primarily by the dynamic loader to load/unload components, but also used by other components to persistently store small amounts of data in a relatively energy-efficient way (compared to MassStorage).
MassStorage: External flash memory chip filesystem. Used to store files (e.g. components, evolution scripts) that arrive over the network, and can of course be used for any other general purpose. Tends to be energy-expensive and slow to use.
Deluge: File propagation protocol. Uses MAC to propagate files to neighbour nodes; files are downloaded into external flash memory. Can of course be replaced with other implementations independently of all other components. Components can register to be notified of when files arrive.
Recon: Evolution script handler. Is notified by file propagation of when files arrive in external flash memory, and on the arrival of evolution scripts, enacts the specified software changes at the local node (provided the evolution script specifies this node's ID or else "all nodes" as a target).
REV: Runtime Evolution Manager. Implements the software evolution primitives of Lorien. Used by Recon to enact the software changes specified in scripts.
Loader: Dynamic loader/linker. Loads object files in which component types are contained; or unloads previously loaded object files.