Friedrich-Alexander-Universität UnivisSearch FAU-Logo
Techn. Fakultšt Willkommen am Department Informatik FAU-Logo
Logo I4
Department of Computer Science 4
  Hello World: First Steps
  Raw Memory Access
  Inter-Domain Comm.
  Service Protection
  CiAO backend
  core module API

Service Protection
  Extending Visibility
Dept. of Computer Science  >  CS 4  >  Research  >  KESO  >  Documentation  >  Service Protection
Service Protection: How to access KESO's system objects

Domains in KESO not only provide spatial isolation but also service protection, that is the use of system services is restricted to only affect entities within the same domain, if sensible/possible. This means, for example, that tasks can only activate tasks within the same domain, occupy resources within the same domain or reconfigure alarms within the same domain. The developer may, however, specifiy exceptions to this, for example it may make system services for a specific tasks possible from a specific other domain. Entities that are subject to service protection are the OSEK operating system level entities tasks, resources and alarms, but also KESO mechanisms such as the Proxy objects required to use the Portal inter-domain communication mechanism.


Service protection in KESO is purely language based. The parameters of system services that are subject to service protection have been changed to object types rather than the primitive values used in OSEK. For example, the ActivateTask() service in OSEK is passed a numeric task id to identify the task that should be activated. The corresponding KESO API in the TaskService, activate(), is passed a Thread object rather than a numeric id. To activate a certain task/thread, the application thus first needs to get hold of the system object (Thread object) of that task. The system objects are provided by a name service, e.g. getTaskByName() in the case of tasks, which will only provide the system object to the caller if the entity represented by the system object belongs to the same domain or has explicitely been made available to that domain. If neither of these conditions is met, the name service will return a null reference.

Thread taskA = keso.core.TaskService.getTaskByName("TaskA"); keso.core.TaskService.activate(taskA); // or alternatively using the standard Java API taskA.start();

Making System Objects available to other DomainsM

The visibility of system objects in KESO can be extended to other domains by defining import statements in the Domain blocks of the configuration file. There is an import statement for each type of OSEK system object: ImportTask, ImportResource and ImportAlarm. The value assigned to the attribute is the name of the system object that should be visible to that domain. The attribute may be defined multiple times in a Domain block to import multiple system objects of one type.

The following example shows how the visibility of Task T1 is extended to the domain B by defining an ImportTask attribute in the domain block of domain B. In this configuration, the getTaskByName() would return the system object for Task T1 when invoked from control flows executing in the context of either domain A or B, but would return null for control flows executing in the context of domain C.

World (Keso) { System (AVR) { Domain (A) { Task(T1) { MainClass = "Main"; } } Domain (B) { ImportTask = "T1"; } Domain (C) { } } }

System Objects and Portal Calls

To retain the statically configured service protection, system objects must not be passed as parameters to portal calls, since this would potentially enable control flows of other domains to invoke system services in a manner that is not apparent from the static configuration file. To avoid this problem, all system object classes implement the NonCopyable marker interface, which means that references to system objects will simply be subsituted by a null reference during a portal call.
  Contact Last modified: 2011-01-18 13:05   MS