fans-rt 0.11版本在近期的测试中发现一些与系统架构上的设计缺陷，主要表现在实时性和空间占用两个方面，在0.12版本中将着重解决这些问题。
1.实时性问题
fans-rt 0.11版本内核架构只支持中断态和用户态，所有内核服务均在中断态执行，在处理耗时较长并需要原子化操作的过程时，会严重影响系统实时性。目前在系统性能测试中发现有以下问题：
系统内存管理服务
从MMS中申请和释放全局内存时，如果需要从一个较大的内存块中申请一个页面，将出现多次分割，在分割的过程中虽然可有响应更高优先级的中断，但如果该中断需要唤醒另一个任务来处理具体事务，将导致任务调度大量延迟。在最大为1024个PAGE的BUDDY配置环境中分配一个页面最多需要耗费4000多个时钟周期(基于stm32 72MHZ环境上测试)，最少需要耗时1200多个时钟周期，按照CPU频率计算，中断延迟最低16us，最大55us。
对象管理服务
对象管理从用户请求进入内核到从HANDLE中解析Class ID和Pool ID，再到调用对象方法，以及在对象中可能处理任务阻塞队列，均在中断态执行，该流程未通过性能测试，但根据对MMS性能测试的结果分析，特别是对任务阻塞队列的处理所产生的中断将更加严重。
任务管理服务
任务管理的任务创建流程的大部分代码被放在用户态的libapi中，分为如下步骤：申请任务上下文对象->申请堆栈->申请局部变量对象->创建局部堆->激活任务(插入任务队列)。任务销毁流程包括如下步骤：销毁局部堆->销毁局部变量对象->销毁堆栈->分离任务(从任务队列中删除)->销毁任务上下文对象。如果销毁流程的所有步骤也采用创建任务相同的方案，在用户态请求内核服务来完成，在堆栈销毁后可能导致任务执行异常，或者在任务分离后导致任务上下文对象泄漏。如果将销毁流程放入IDLE中处理则可能由于IDLE的优先级太低而不能即使释放资源，最终导致创建新任务失败，目前采用在内核中断态释放所有资源的方式，在释放堆栈时需要调用MMS服务的功能，在双堆栈环境上将导致2倍于MMS的中断延迟。
内核服务管理器
内核服务管理器在查找内核服务功能时虽然通过HASH优化能够快速找到需要执行的功能，但在处理入参有效性判断、服务功能有效性判断等需要消耗一些时钟周期，而这些条件判断均在内核服务中断中完成，加剧了中断延迟现象。
内核服务中断上下文处理
由于所有内核服务均通过内核服务中断处理，在中断上下文的现场保护中对寄存器的保存和弹出均需要消耗CPU时钟周期，将直接导致中断延迟。
由于内核服务中不能执行耗时较长的复杂操作，只能将各种复杂的流程划分为若干个功能单一的内核服务，过多的内核请求会浪费大量的CPU时钟周期，这将导致整个系统性能低下，在一些频率和速度较低的SoC系统中，对系统性能产生严重影响。
2.堆栈嵌套深度和FLASH占用过多的问题
fans-rt 0.11版本在所有硬件形态上均采用内核态加用户态的设计架构，对于大容量的计算机系统来说这是一个恰当的架构，但相对于小容量的MCU这就属于一个臃肿的架构。
过多的层次架构
应用层请求内核服务功能需要通过libapi->libcal->lpc->coreservice逐层调用进入core service已经处于第4层，请求包、局部变量以及每一层函数的参数传递等会导致对堆栈空间的需求急剧攀升，难以在容量较小的MCU上运行。另外，过多的代码层次也会占用更多的FLASH空间。
内核服务中断的堆栈占用
由于所有内核服务均通过内核服务中断处理，对中断上下文的保存需要占用堆栈空间，以cortex-m系列arm处理器为例每进入一层中断需要对8个寄存器入栈，占用32个字节的堆栈空间。在内核服务中断执行过程中发生更高优先级的中断，则需要至少64字节的堆栈空间。