## 5 OS Conformance
### TinyOS  
TinyOS conforms to the majority of the design rules, but not all of them. The most significant drawback is the complexity of the TinyOS architecture. Although TinyOS is portable (the wide range of supported platforms is a proof for it), code readability and simplicity is doubtful. The main reasons for TinyOS complexity are:  
\begin{table}
\begin{tabular}{c l c c c c} \hline \hline
**\#** & **Rule** & **TinyOS** & **Contiki** & **LiteOS** & **MansOS** \\ \hline \multicolumn{5}{c}{General} \\ \hline
1 & Simple, efficient networking protocols & + & + & \(\pm\) & + \\
2 & Sink-oriented protocols & + & + & & + \\
3 & Base station example & + & & + & + \\ \hline \multicolumn{5}{c}{Sensing} \\ \hline
4 & Temperature, light, acceleration API & & & \(\pm\) & + \\
5 & Low duty cycle sampling & + & + & + & + \\ \hline \multicolumn{5}{c}{Lifetime and energy} \\ \hline
6 & Auto sleep mode & + & + & + & + \\
7 & Powered mode in protocol design & + & + & & + \\ \hline \multicolumn{5}{c}{Sensor mode} \\ \hline
8 & TelosB support & + & + & & + \\
9 & Rapid driver development & & + & + & + \\
10 & Rapid platform definition & & \(\pm\) & & + \\
11 & CC2420 radio chip driver & + & + & + & + \\
12 & AVR and MSP430 architecture support & + & + & \(\pm\) & + \\
13 & External storage support & + & + & + & + \\
14 & Simple file system & & + & + & + \\ \hline \multicolumn{5}{c}{Communication} \\ \hline
15 & Configurable packet payload (default: 30 bytes) & + & + & + & + \\
16 & Configurable transmission power & + & + & + & + \\
17 & Protocols for \(\leq\) 1 Mbps bandwidth & + & + & + & + \\
18 & Simple proactive routing & + & + & \(\pm\) & + \\
19 & Simple CSMA MAC & + & + & & + \\
20 & Custom MAC and routing API & + & + & & + \\
21 & IPv6 support & + & + & & \\
22 & Simple reception acknowledgment & + & + & & + \\ \hline \multicolumn{5}{c}{Tasks and scheduling} \\ \hline
23 & five kernel and six user task support & + & + & \(\pm\) & \(\pm\) \\
24 & Cooperative and preemptive scheduling & + & + & & + \\
25 & Simple time synchronization & & + & & + \\ \hline \hline \end{tabular}
\end{table}
Table 18: Existing OS conformance to proposed design rules.  
* The event-driven nature: while event handlers impose less overhead compared to sequential programming, with blocking calls and polling, it is more complex for programmers to design and keep in mind the state machine for split-phase operation of the application
* Modular component architecture: a high degree of modularity and code reuse leads to program logic distribution into many components. Each new functionality may require modification in multiple locations, requiring deep knowledge of internal system structure
* neSC language peculiarities: confusion of interfaces and components, component composition and nesting and specific requirements for variable definitions are examples of language aspects interfering with the creativity of novice WSN programmers  
These limitations are at the system design level, and there is no quick fix available. The most convenient alternative is to implement middleware on top of TinyOS for simplified access to non-expert WSN programmers. TinyOS architecture is too specific and complex to introduce groundbreaking improvements for readability while maintaining backwards compatibility for existing applications.  
There are multiple TinyOS inconsistencies with the proposed design rules, which can be corrected by implementing missing features:  
* TinyOS provides an interface for writing data and debug logs to external storage devices; yet, no file system is available. Third party external storage filesystem implementations do exist, such as TinyOS FAT16 support for SD cards [85].
* TinyOS contains Flooding Time Synchronization Protocol (FTSP) time synchronization protocol [9] in its libraries. However, it requires deep understanding of clock skew issues and FTSP protocol operation to be useful
* The temperature, light, acceleration, sound and humidity sensing API is not provided