harmonizing policy management with murphy in genivi, agl ... · •solution in the poc ‒for...

Harmonizing policy management

with Murphy

in GENIVI, AGL and TIZEN IVI1

Long term TIZEN Objectives for harmonization

2

• Support in TIZEN for coexistence of GENIVI applications

• Allow portable business rules

• Harmonize HW adaptation

Murphy introduction

3

What is Murphy?

4

• Policy Management framework

• Open source projecthttp://01.org/murphy

• Liberal licensing

• The policy management framework in TIZEN IVIhttp://review.tizen.org/gerrit - sourceshttp://download.tizen.org - packages

What does the `policy management framework´ mean?

5

• Toolkit to build policy engines‒ Support libraries to make easy to

• write plugins• manage data (ie. Murphy provides a memory resident database)• communicate (over D-Bus, web socket, or export/import DB tables)• build logic networks

‒ LUA scripting• Can be used achieve portability

• Set of readily available frameworks that‒ Can be used without change‒ Can be modified/extended to fulfill special needs

• by scripting• by forking, ie. modifying/extending the existing plugins

‒ Can serve as an example how to write something new/different

What are the `readily available frameworks´ in Murphy?

6

• Audio management‒ Playback right management

‒ Routing

‒ Volume control

• Screen management‒ Layout management

‒ Visibility management

‒ Input management

• System resource management‒ Tracking

‒ Limit setting

Policy Model

7

Centralized decision• in Murphy daemon

• decision support data collected from

• system daemons

• policy aware applications

• domain servers

Distributed enforcement• in various domain controllers

• domain controllers are either

• plugins in a domain server

• plugins in murphy daemon

MurphyDomain

Controllers

Applicationspolicy unaware

DomainServers

Murphydaemon

SystemDaemons

Applicationspolicy aware

Architecture and operation

8

Murphydaemon

1. system state change

2. data collection

3. trigger decisions

4. store decisions

5. export decisions

6. enforce decisions

MurphyDB

Data Source

Domaincontroller

Decision Logic

2 5 61

3 4

Logic can span over multiple components

9

• DB tables can be exported/imported‒ single writer; multiple consumers

• DB exports‒ implemented by domain controller using domain control support library‒ exporting is triggered by database changes

• DB imports‒ domain controller can create/update DB tables in Murphy daemon

Murphy daemon Domain Controller

Domain Controller

Plugin

Domain Controller

LibraryLogicLogic

Multi host support

10

domaincontrollers

domaincontrollers

Centralised Distributed

SingleMurphy daemon

MasterMurphy daemon

SlaveMurphy daemon

domaincontrollers

domaincontrollers

host #1

host #2 host #2

host #1

Network Network

Audio Management

Harmonization of TIZEN and GENIVI audio stacks

11

PoC for harmonization of TIZEN - GENIVI

12

• Intel & ADIT currently make a joint effort to harmonize GENIVI & TIZEN audio stacks

• The resulting components will be open sourced

• The results will be part of future releases of Tizen

• the PoC will be the basis for GENIVI audio support in TIZEN

• GENIVI might consider to include also the resulting components and Murphy

Motivation for building the PoC

13

• Co-existence of TIZEN and GENIVI Audio applications

‒ Audio management in TIZEN and GENIVI are different

‒ Murphy and the GENIVI Audio Manager should be integrated

• Exploring how Murphy can be used

‒ See and learn the lessons how actual IVI audio use cases and environment can be implemented

‒ Make adjustments if needed

‒ Hope this attempt will be the starting point for policy management in IVI

Overview of GENIVI audio management

14

• Central management point inGENIVI Audio Manager

• Support for multiple domains

• “Brain” of audio policy is implemented in the Control Plugin

• Hardware adaptation is in the Router Plugins

• Applications are expected to request routes (connections) before playing back or capturing

Example for GENIVI audio management

15

routing / volume

GENIVI application

Linux Audio Server (ALSA)

Co

ntr

ol

Plu

g-in

Routing Plug-inFor ALSA

Routing Plug-inFor DSP

Command InterfacePlugin

GENIVI Audio Manager

GENIVI application

DSP

• Central management point inGENIVI Audio Manager

• Support for multiple domains

• “Brain” of audio policy is implemented in the Control Plugin

• Hardware adaptation is in the Router Plugins

• Applications are expected to request routes (connections) before playing back or capturing

Overview of audio management in TIZEN IVI

16

• Central management point in Murphy

• Enforcement point in the Sound Server

• Supports a single domain only

• Support for both policy aware and policy unaware applications

BlueZ

module-murphy-ivi plugin PulseAudio

ASMresource

pluginMurphy

ALSA

WRT application(policy aware)

Linux application(policy unaware)

Harmonization challenge: explicit vs. Implicit routing

17

• explicit routes

‒ GENIVI model

‒ applications explicitly set the routing targets

‒ an audio source can have 0+ explicit routes

‒ explicit routes are static, e.g. connecting new headsets will not effect existing explicit routes

• implicit routes

‒ WebRuntime and Linux applications

‒ automatic @ stream creation

‒ default routes determined by the stream class which in turn determined by a stream property and/or the name of the exe image

‒ an audio source can have 0 or 1 default route

• default routes are dynamic, eg. connecting a new headset might change the routing

Harmonization challenge: static vs. dynamic sinks/source

18

• Many Tier1 prefer static setups

‒ GENIVI Audio Manager supports both dynamic and static setups

‒ Pulseaudio (what is used in Tizen) supports just dynamic setups

• Solution in the PoC

‒ For GENIVI

• simulated static setup

• sink/sources appear all the time

• for sinks/sources that are implemented by applications availability changes as the application runs/exitse.g. a source implemented by an MP3 player become available when the player app runs and become unavailable when the app exits

‒ For TIZEN

• The usual dynamic setup

Harmonization challenge: routing logic

19

• GENIVI

‒ If an application wants to play

• It has to request a route (connection)

• Application should be aware of its own sink/source andthe routing target (the other end of the connection)

• TIZEN

‒ If an application wants to play it has to either

• create the stream and start to play (policy unaware apps)

• ask for playback rights beside creating a stream (policy aware)

‒ In both cases the policy engine determines the routing target ie. the source or sink

• The logic to determine the routing target is in a PulseAudio plugin (pulseaudio-module-murphy-ivi)

• In order to support multiple audio domains the logic had to be moved from PulseAudio to Murphy

How will the GENIVI Audio Manager will be supported in TIZEN

20

BlueZ

DSP

module-murphy-ivi plugin PulseAudio

GA

Msu

pp

ort

p

lugi

n

esourceplugin

Murphy

ALSA

GENIVI application

WRT application

Linux application

Routing volume

Implicit routing

logic

Mu

rph

yco

ntr

ol

plu

gin

D-BusRouter Interface

Plugin

DSPRouter Interface

Plugin

Command Interface

Plugin

Genivi Audio Manager

PoC components

Example flow

21

D-BusRouter Interface

Plugin

DSPRouter Interface

Plugin

Command InterfacePlugin

Genivi Audio Manager

BlueZ

DSP

module-murphy-ivi plugin PulseAudio

GA

Msu

pp

ort

p

lugi

n

resourceplugin

Murphy

ALSA

GENIVI application

WRT application

Linux application

Routing volume

Implicit routing

logic

Mu

rph

yco

ntr

ol

plu

gin

PoC test setup

22

mp3

Gat

way

1

Gat

way

2

Gat

way

3

DSP Domain

PulseAudio Domain

Radio GENIVI application

WRTapplication

ICOapplication

Gat

way

4

NavigationGENIVI application

ALSA Domain

Gat

way

5

Gat

way

6

Harmonized HW adaptation

23

• If you need to adapt new audio HW like DSP or external AVB amplifier ...

• Write a Router Plugin for GENIVI Audio Manager and you can use your HW in

‒ TIZEN for both• TIZEN apps (assuming your HW has ALSA PCM devices)

• GENIVI apps

‒ GENIVI platforms

Screen Management

24

Overview of Screen Management in TIZEN IVI

25

Weston Backends (drm, X11, ...)

Weston Core

ivi-shell

plugin

libivi-layout.so

ivi-controller.so hmi-controller.so

GENIVI application

Libilm_client.so

ivi-application protocols

Murphy

ivi-controller protocol

HomeScreen

libwayland-client.so

Wayland & Weston protocols

libwayland-server.so

TIZEN application

Screen Management main building blocks

26

• Regulator‒ Logic to adapt vehicle state, driver activities and application usage scenarios‒ Set of rules and/or state machines‒ Determines what applications can be active

• Layout Manager‒ Manages Areas and Layers‒ Assigns and moves surfaces to areas/layers‒ Depends on Regulations

• Resource Manager‒ Decides what active applications can do and when‒ Depends on Regulations

• Application Launcher / Task Switcher‒ Launches/kills application‒ Requests to switch active application

• Screen Controller‒ Carries out / enforces the decisions of Layout & Resource Manager

• Input Controller‒ Carries out / enforces the decisions of Input & Resource Manager

Screen Management in TIZEN M14.3 release

27

WestonMurphyHome Screen

LayoutManager

LayoutManager

LauncherTask Switcher

ResourceManager

Regulator

ScreenController

InputManager

InputManager

InputController

Implemented in ivi-shell & ivi-contoller

Screen Management PoC after TIZEN M14.3 release

28

WestonMurphyHome Screen

LayoutManager

LayoutManager

LauncherTask Switcher

ResourceManager

Regulator

ScreenController

InputManager

InputManager

InputController

LayoutManager

InputManager

Harmonized HW adaptation

29

• If you need to adapt new graphics HW ...

• Write a backend for Weston and you can use your HW in

‒ TIZEN for both• TIZEN apps (assuming your HW has ALSA PCM devices)

• GENIVI apps

‒ GENIVI platforms

Lifecycle ManagementHarmonization of TIZEN and GENIVI system resource management

30

System resource management in TIZEN

31

• Murphy can track‒ Memory usage (MemFree, SwapFree, Dirty, Writeback)‒ CPU load (Combined single virtual CPU, Per physical CPU, Per Cgroup)

• Murphy can notify‒ For notifications CPU and Memory watches can be defined

• The whole tracked value range is split into zones• Callbacks are set for each watch

‒ If a watched value goes from a zone to another the specified callback is called

• Murphy can setPer Cgroup

• Memory (limit_in_bytes, soft_limit_in_bytes, memsw.limit_in_bytes, swappiness)• CPU (shares, cfs_period_us, cfs_quota_us, rt_period_us, rt_runtime_us)• Freezer (state)

• Scriptable logic

Harmonization efforts

32

• Ongoing discussion with GENIVI folks

• Possible scenarios

‒ No harmonization at all

‒ Provide in TIZEN some of the GENIVI lifecycle management API’s using MurphyFirst target is the GENIVI Resource Management which is the counterpart of TIZEN system Resource Management

‒ The Murphy implementation could be used also in GENIVI

Future works in TIZEN

33

• Support for new Cgroup controllers

‒ net_cls (network bandwidth control)

‒ blkio (storage I/O bandwidth control)

• Application tracking

‒ Note: applications and processes are not necessarily the same• Web Runtime

• Threads, forks execs understood and handled properly

‒ Watches for applications• Similar mechanism what Murphy already has to track CPU and Memory usage

• Improvements to the existing features

‒ per Cgroup memory monitoring

Summary

34

Summary

35

• Harmonization areas‒ Audio Management

‒ Screen Management

‒ System Resource Management

• Achievement of objectives‒ Support in TIZEN for coexistence of GENIVI applications

• Audio Management: integration of Murphy and GENIVI Audio Manager

• Screen Management: use of Weston + IVI shell + Wayland IVI extension + integration of Murphy to Weston

‒ Allow portable business rules• Murphy’s configurability and scriptability

‒ Harmonize HW adaptation• Audio Management: GENIVI Audio Manager + Router Plugin

• Screen Management: Weston + backend