As performance of devices become high and growing networks between the devices, parallel and distributed systems providing advanced features become popular. It is hard to verify the behavior of such systems' design with traditional techniques, such as manual reviews and simulations, because of so many possibilities of the behavior. Model Checking is the one of promising techniques to tackle the difficulty. In this paper, we introduce the background of Model Checking techniques and show five popular model checking tools with the case studies and current research topics.
In software product-line development (SPLD), variability management plays an essential role, and multiple variability modeling methods have been proposed. Along with gradual acceptance of SPLD and diversifications of the usage of variability models, there have been proposed various enhancements on these models. In this tutorial paper, we focus on feature model, a representative variability model. We firstly introduce the original feature model and some extensions made on the model, and then introduce how these models are used in SPLD activities.
With the increase in hardware performance of modern embedded systems, general-purpose operating systems (OS) such as Linux are commonly used as embedded OSs. Furthermore, the use of multi-core CPUs enables Linux to improve its real-time performance even on high-load scenarios which is rather hard to achieve on single-core CPUs thanks to its “CPU affinity” functionality. However, we found two issues in the current version of the Linux kernel: the CPU affinity of some kernel threads cannot be specified; and the use of timer cascading (use of multiple hardware timers to count time) increases the worst-case response time of real-time tasks. In this paper, we classify the cores in a multi-core CPU into 2 different groups: cores which require real-time performance guarantees; and cores which do not require such guarantees. Then, we propose and evaluate a method that improves the real-time performance of the system by disabling timer cascading on cores which require real-time performance guarantees.
This paper describes HR-TECS which is a new component technology for embedded software that requires memory protection, which is one of the important features for the software partitioning. HR-TECS is based on TECS which is a component technology for embedded software, and takes advantage of functionalities of a real-time operating system with memory protection. In addition, interfaces for communications between components do not depend on partitions which the components are allocated to. Thus, components can be implemented without consideration for the component partitioning. Furthermore, not only components which are executed in a user mode (e.g. application software) but also components which are executed in a privileged mode (e.g. device drivers) can be developed with HR-TECS. This paper presents the way to implement HR-TECS by taking advantage of TOPPERS/HRP2 kernel which is a real-time operating system with memory protection. The results of evaluation demonstrate the effectiveness of HR-TECS that its execution time is sufficiently small and predictable, and its memory consumption is sufficiently small.
This paper presents how to construct a weighted type-error slice without reimplementing a type inference engine. In the previous type-error slices, we had no information on the source of the type error in the slices. However, we encounter many examples where the possibility that the source of a type error in a slice is not uniform. In this work, we present a weighted type-error slicer. We provide information on how often each part of a slice contribute to type conflicts. The advantage of our approach is twofold. First, we use compiler's type inference engine to make type-error slices. By not reimplementing it, we can obtain scalability and maintainability. Second, we have weights on type-error slices. We can use the information to improve the behavior of type debuggers. In this paper, we introduce an embedded type-error slicer. After that, we extend it to introduce weights.