**2.4 Software partition protection mechanism design**

i.Partition protection requirements

Avionics systems can implement multiple functions to share resources. The functional entities (which can be software modules, hardware modules) that share resources are called partitions. The partitions of the original avionics system shared resources, but sharing would bring potential problems described below:


Therefore, the design of system software architecture of the avionics system should meet the reliable partition protection to avoid the above problems.

## ii.Partition protection design

The partition protection design of onboard system software in avionics systems includes the following three aspects:

• Space protection. For processors with Memory Management Unit (MMU) support, such as X86 processors, it is stipulated that the partition itself cannot directly access physical memory, and only virtual memory can be accessed through the MMU memory mapping table configured for each

partition by system software. For processors without MMU support, taking the Scalable Processor Architecture (SPARC) processor as an example, during partition initialization, the system software protects the SRAM by setting the privileged register to achieve partition space isolation.

	- Blueprint only registers the interfaces on the modules and then mounts them on the app as a whole. The purpose of blueprint itself is to organize the parallel coexistence of multiple modules and avoid registering modules directly on the app. In fact, it is more convenient for development and code maintenance, because ultimately all interfaces on views are still directly mounted on the app, which corresponds to the entire application; there is no obvious difference [11].
	- Blueprint is not a pluggable application, because it is not a real application, but a set of operations that can be registered in the application and can be registered multiple times.
	- At the same time, we cannot use multiple objects to manage and register, because this will cause each object to have its own configuration, which is not easy to manage.
	- With blueprint, the application will be managed in the flask layer, share the configuration, and change the application object on demand through

registration. The disadvantage of blueprint is that once an application is created, it can only be unregistered by destroying the entire application object.
