On a conceptual level RTEMS can be characterized by three layers: hardware support, kernel and APIs. The user then develops his application by using the available APIs . The next image gives another perspective into this.
The hardware support layer encompasses the processor and board dependent files as well as a common hardware library. There is a direct mapping of this layer into the following directories: libcpu, libbsp and libchip.
One aspect that can be noticed from the above image is that both the kernel and the API layers are part of the so called RTEMS executive. The notion of executive expresses the capability to run applications, implying to use an API set for applications development. Additionally to that, the RTEMS executive source code can be mapped to a single directory: cpukit. However, from a conceptual level the kernel itself and the APIs are two distinct ideas.
The kernel layer is the heart of RTEMS and encompasses the super
core , the super API and several portable support libraries . These components correspond to the score, sapi and the several lib subdirectories inside cpukit. The super core is organized into handlers and provides a common infrastructure and a high degree of interoperability between APIs. It is worth reminding that there is a small part of the super core that is target dependent. The super API contains the code for services that are beyond any standardization, such as API initialization and extensions support.
The API layer makes the bridge between the kernel and the application. The Classic, POSIX and ITRON APIs are implemented in terms of super core services. Each API is organized into managers (the right side of the image illustrates that). The Ada API is a direct mapping of the Classic interface.