2019 IEEE Real-Time Systems Symposium (RTSS)

Design and Dynamic Update of Real-Time Systems

(Invited Paper)

Wang Yi
Department of Information Technology, Uppsala University, Sweden
Email: [email protected]

I. C HALLENGES efficient solutions only if the intended updates can preserve

and ensure the following safety conditions:
Technology solutions are becoming utterly dependent on
 functional correctness: including that the new com-
software. Today, the functionality of most industrial systems
ponents (or applications) must not interfere with the
and products such as cars, smart phones, and medical
existing system, e.g., they will not block each other due
devices is implemented by software as embedded real-time
to shared data or resources, and their inputs and outputs
system. The reliability of these systems is fundamental to
should be compatible, satisfying required relationships,
the functioning of our society, as evidenced by accidents
and
reported in recent years, e.g., involving self-driving Tesla
 nonfunctional correctness: including that the computing
cars controlled by software.
platform must have sufficient computational resources
The current trend is that today’s mostly closed and single-
to execute the new components without being over-
purpose embedded real-time systems will become open
loaded or violating any timing requirements.
platforms. They will allow integration of an expanding
number of software components over their life-time e.g., in A crucial obstacle is that embedded real-time systems built
order to enhance and customize their functionality according today are often impossible to modify or extend with new
to the varying needs of individual users, and to defend components after deployment due to their inadequate system
against upcoming security threats. To enable this, we must architectures not prepared for updates. Any changes may
have systems that support dynamic updates on-demand, but crash the original system and/or jeopardize the safety of the
still retain their safety properties. To be feasible, and to resulting system. For smartphones, one may simply uninstall
ensure that the resulting systems stay safe, software updates the new components. A car, on the other hand, is a safety-
must be performed in a component-wise and incremental critical system, which must satisfy crucial safety and timing
manner without demanding re-designing/updating/verifying requirements on braking, driver assistance, etc. A single
the whole system. instance of violating such requirements may result in serious
As an example, cars offer a shared computing platform en- accidents or loss of human lives.
abling new applications to be deployed over multiple smart While re-designing the whole system is not a feasible
sensors and electronic control units for better performance option, the existing approach today to extensively re-test
and new functionalities (e.g., more fuel-efficient engine the entire resulting system configuration in the lab for up-
control, lane following, pedestrian detection). For trips in dates [4] will not scale for future systems. The sheer number
Northern Europe, we may want to install applications for of possible system states and configurations prohibits testing
black ice- and elk-detection to drive safely; whereas, for trips them all. Our vision is to change the way how today’s
in Southern Europe, software that optimizes regenerative real-time systems are developed and provide the missing
breaking with hot batteries in humid conditions would be design paradigms and technologies for constructing real-time
more useful. Other examples are pacemakers. Over time systems on composable architectures prepared for future
(e.g., due to aging), a patient carrying such a medical device (component-wise) modifications, that can be updated on
may develop a new heart problem. To treat the emerging demand after deployment incrementally, dynamically, safely
disease, doctors may propose installing a new application and securely over their operational life-time. To fullfil this
instead of replacing the device with a new one, which would vision, we believe the following key challenges must be
require a surgery. addressed:
Unfortunately, current design methodologies for real-time  The design challenge to build updatable systems: we
systems offer only limited support for software updates on must develop a new composable architecture and exe-
systems in operation. Such updates are not possible today cution model for real-time systems, well prepared for
for systems like cars since the resulting systems can not future incremental updates, allowing new and updated
be guaranteed to remain safe. The examples show clearly components to be seamlessly integrated while guar-
that incremental updates may lead to more reliable and cost- anteeing their deterministic input-output and timing

2576-3172/19/$31.00 ©2019 IEEE 1

DOI 10.1109/RTSS46320.2019.00011

Authorized licensed use limited to: Auckland University of Technology. Downloaded on June 05,2020 at 20:09:09 UTC from IEEE Xplore. Restrictions apply.
 behaviors, a crucial property for safety-critical systems. system functions onto a platform by introducing a software
 The verification challenge to ensure safe updates: we layer in the design architecture (see Fig. ??). This middle
must develop scalable automated methods for verifica- layer is to be realized using multitasking run-time sys-
tion of functional and nonfunctional correctness prop- tems, where system functions are executed using real-time
erties of real-time systems, and build a next generation tasks. The tasks execute independently and communicate
of software tools for rapid in-the-field verification prior asynchronously, thereby avoiding interference between the
to performing any intended updates to ensure the safety existing functions and the new ones in case of updates.
conditions. The decoupling of tasks in the software layer addresses two
 The run-time challenge for resource efficiency: we must serious drawbacks of previous approaches. First, static or
develop efficient scheduling algorithms and schedula- overly determined time schedules are avoided by making
bility analysis techniques, which not only guarantee component interaction asynchronous. Second, the scheduling
timing and resource requirements, but also optimize of task sets onto complex platforms becomes tractable, since
run-time resource utilization on state-of-the-art (het- tasks are independent and the need to consider complex
erogeneous) multiprocessor and distributed platforms to resource and data dependencies disappears.
enable dynamic updates over the operational life time Our design architecture is structured into three layers
of systems. shown in Fig. 1 (similar to the AUTOSAR reference model
for automotive systems1 ), where arrows within a layer
II. A PPROACHES AND P ERSPECTIVES represent flow of data, and arrows between layers correspond
One of the major technical challenges in real-time systems to implementation relations.
design is to ensure that the resulting system has deter- 1) At the top is the function layer, where system func-
ministic input-output and timing behavior (typically with tions are specified as data-flow chains (or diagrams
deterministic input-to-output latencies) even when multiple in general) of basic components (similar to, e.g., the
system functions are integrated and co-execute on a plat- runnables in AUTOSAR). The resource requirements of
form with limited resources. The deterministic semantics the components are mapped to the tasks of the software
allows model-in-the-loop simulation using successful tools layer, to ensure that the platform has enough resources
like Simulink/Stateflow to simulate and verify the complete to satisfy nonfunctional requirements of system func-
system behavior. tions. The decoupling between components achieved
Over the past decades, numerous approaches to address by the software layer greatly simplifies verification of
this challenge have been devised by research communities functional and timing requirements, since each system
in hardware, software, control, and communication. Several, function can be verified separately. We will develop
including the synchronous approach, embodied by the lan- an interface theory for this purpose. To further achieve
guages Esterel, Lustre, and Signal [1], and the time-triggered the needed efficiency, functional and nonfunctional
paradigm promoted by Kopetz [2], ensure deterministic aspects will be strictly separated. Functional properties
behavior by scheduling computation and communication are verified by efficient SMT-based methods while
among components at pre-determined time points. This re- timing and performance are handled by Digraph-based
sults in highly reliable and predictable systems, but severely workload models [5]. This will enable us to avoid
restricts the possibility to modify or update systems after the scalability problems encountered even by the best
deployment. The reason is that new components must fit existing verification tools such as UPPAAL, which mix
exactly into the already determined time schedules and functional and nonfunctional properties.
components may perturb each others’ timing via shared 2) The middle software layer consists of stand-alone real-
resources. Other approaches develop techniques for directly time tasks that execute independently and communicate
scheduling sets of system functionalities, represented as asynchronously via non-blocking data buffers. It must
tasks with known resource needs, onto a given platform. also preserve the deterministic input-output and timing
For simple periodic tasks deployed on uniprocessors, there behavior of system functions. This is a difficult chal-
are well-understood technologies, such as rate-monotonic lenge, which has not been overcome in previous de-
scheduling [3]. For task sets with data dependencies, and for sign approaches. We will develop novel data buffering
heterogeneous platforms, the scheduling problem becomes protocols and scheduling techniques for this purpose.
extremely difficult, and not tractable in the face of updates. The software layer can be seen as an abstraction of the
We proposes a new approach as outlined in [6] to ad- computation and communication resources to provide a
dressing the challenge of building real-time systems, which uniform form of requirement for the hardware layer. For
on the one hand ensures deterministic input-output and example, in the case of a distributed platform, a network
timing behaviors, and on the other hand supports incremental
updates without re-design of the whole system. The main 1 However, AUTOSAR has no support [4] for updates or preserving the
idea is to decompose the problem of implementing a set of deterministic semantics of systems.

Authorized licensed use limited to: Auckland University of Technology. Downloaded on June 05,2020 at 20:09:09 UTC from IEEE Xplore. Restrictions apply.
 F1 f2 f9 [4] S. Saidi, S. Steinhorst, A. Hamann, D. Ziegenbein, and
f1 f10 Mapping
F3
M. Wolf. Future automotive systems design: research chal-
Function f5 f6 f7 f12 lenges and opportunities. In CODES+ISSS 2018.
f11
Layer
F2 f8 f15
f16
f3 f4 [5] M. Stigge, P. Ekberg, N. Guan, and W. Yi. The digraph real-
time task model. In RTAS 2011.
T2 T6
T8
Software T4
[6] W. Yi. Towards customizable CPS: composability, efficiency
Layer T1
T3 NL1 T9
NL2 T7 and predictability. In Formal Methods and Software Engineer-
ing - 19th International Conference on Formal Engineering
Methods, ICFEM 2017, Xi’an, China, November 13-17, 2017,
Hardware CPU CPU Network CPU
Proceedings, pages 3–15, 2017.
FPGA GPU
1 2 BW 3
Layer

Figure 1. The design architecture: an overview.

link shall be abstracted as a task which transmits data

from one processing node to another, whose resource
budget represents the worst-case transmission time.
3) The bottom hardware layer consists of hardware re-
sources for computation and communication on the
actual platform, which may be heterogeneous and/or
distributed. We will develop new techniques for map-
ping and scheduling of the software layer onto the
hardware layer.
Systems built following the design architecture support
updates with new or updated components in (at least) the
following ways.
 Prior to any update, it is verified that the resulting sys-
tem will satisfy the specified functional requirements.
This uses only the component contracts of the function
layer.
 To check that the platform has enough resources to
satisfy nonfunctional requirements of the resulting sys-
tem, the mapping to the software layer is adjusted to
accommodate also the resource requirements of the
new components. In some cases, this can be done
without altering the software layer. In other cases, task
parameters such as periods or resource budgets must
be adjusted; it must then be checked whether the new
software layer is schedulable.
ACKNOWLEDGMENT
The work is partially supported by the ERC advanced
grant: CUSTOMER with grant no. 834166.
R EFERENCES
[1] N. Halbwachs. Synchronous Programming of Reactive Systems.
Springer US, 2013.

[2] H. Kopetz and G. Bauer. The time-triggered architecture. Pro.

of IEEE, 2003.

[3] C. L. Liu and J. W. Layland. Scheduling algorithms for

multiprogramming in a hard-real-time environment. JACM,
1973.

Authorized licensed use limited to: Auckland University of Technology. Downloaded on June 05,2020 at 20:09:09 UTC from IEEE Xplore. Restrictions apply.