|The core of all eT-Kernel profiles, “eT-Kernel Compact”, has been certified to the following Functional Safety standards.
・ISO 26262 ASIL D (for automotive)
・IEC 61508 SIL 4 (for industrial equipment)
eT-Kernel Safety Package Lineup
For users who strive to conform with functional safety standards, eSOL offers the following eT-Kernel Safety Packages, including various documents including a safety Manual and Safety Reports.
Open source T-Kernel has been extended
High-speed operation for the entire system with "Fast Boot"
"Logical File System (LFS)" offers transparent access to multiple file systems
"Exception Manager" offers problem-solving support while the system is running
"Target Shell" adds extended commands, useful for final system maintenance and inspection
Compliance with POSIX specifications, and appropriation of UNIX assets including Linux (software/engineering resources) helps improve development efficiency
Multi-core compatibility using a unique scheduling method makes it possible to mix SMP and AMP
System protection function helps to ensure multi-core system quality and reliability
Unique verification in addition to standards test suite
Compatibility with T-Kernel is retained
eT-Kernel retains backward-compatibility with Tron Forum’s T-Kernel 2.0. eSOL is certified by Tron Forum to distribute a modified version of their product, so that you can use eT-Kernel with peace of mind.
Three profiles available
|RTOS compliant with POSIX specifications|
|RTOS for large-scale systems, featuring memory protection and process model|
|Compact RTOS with remarkable real-time capability, with a structure resembling μITRON
Multi-core compatible, able to mix SMP and AMP
eBinder offers an efficient development for all three profiles
Logical File System supports POSIX file system APIs
Successfully implemented in various fields
Source code and documentation provided
Maintenance and customization services
T-Kernel’s software architecture features a flexible, layer-type scalable structure, allowing you to change it accordingly to match the system you’re developing. Various setups are available to promote re-use of software. A simple explanation of each program feature that makes up the architecture is provided here.
T-Kernel consists of: The T-Kernel/Operating System (T-Kernel/OS), the T-Kernel/System Manager (T-Kernel/SM), and T-Kernel/Debugger Support (T-Kernel/DS). The list below shows their functions. T-Kernel/OS is the main part of T-Kernel and includes all task management features, memory management features, and system control features included in a standard realtime OS such as µITRON. T-Kernel/OS can only be called T-Kernel in a strict sense.
- Task management
- Task-included synchronization
- Task-excluded processing
- Synchronization / communication
- Memory pool management
- Time management
- Interruption management
- System status management
- Subsystem status management
- System memory management
- Address space management
- Device management
- Interruption management
- I/O port access support
- Energy saving management
- System structure information management
- Memory cache control
- Physical timer
- Subsystem and device driver operation
- Kernel internal status acquisition
- Execution trace
eT-Kernel follows the device driver specifications prescribed for driver interfaces and drivers. When transitioning programs that use a driver to a new hardware environment, driver interface standardization allows you to re-use applications such as middleware and libraries without changing interface parts.
A subsystem is a setup used for expanding T-Kernel functions. As shown in the diagram, subsystems operate in T-Kernel, with T-Kernel/OS offering a subsystem management function. T-Kernel can also be statically linked to or statically loaded. For example, middleware such as the file system and the TCP/IP protocol stack can be implemented as subsystems. User-created unique libraries, etc. can also be added as subsystems. By implementing middleware or user-created libraries as subsystems, a shared interface can be provided for upper-level applications. Also, since subsystems do not depend on a CPU or board thanks to the layer-type T-Kernel architecture, subsystems simply need to be recompiled to operate when changing hardware, with no repair necessary.