Policy Manager Project.

Hoyer, Marko (ADITG/SW2) mhoyer at de.adit-jv.com
Fri Mar 17 03:52:12 EDT 2017

Hello Magnus,

Sounds interesting.

It fits sort of to some concepts we discussed long time ago with the CE group around device management. I suggested a device management approach (as an alternative to the centralistic approach the device manager is focusing on) in which device management is distributed over different components in a very simplified way, this works as follows:

-        Usb stick is attached

-        Kernel prepares it as mass storage device and signals user space

-        An automounter detects it and mounts the partitions

-        Once it is done, someone looks at the content and decides based on the content who is informed about the new partitions available for reading now

o   In case a navi map is on, navi is informed

o   In case of media on it, the indexer and mediaplayer are informed

o   In case of an update package, software manager is informed

o   …
This is just one example. The generic approach behind works most probably for different other devices as well.

Your approach fits somehow to this idea in a way that the policy manager you are mentioning fits pretty well to the component deciding where in the net of device management components the events are floating depending on the context, a customer project specific policy, and maybe some user interaction as well. Take a look into the slides I attached if you are interested in some more details …

I’d like to point out two challenges I see with your idea:

-        You might need very use case / domain specific states in your policy manager (e.g. “i-phone_connected _and_currently_in_role_switch_mode”)

-        For a decision, you might need very use case / domain specific information (e.g. “the usb stick attached and mounted at /media/xyz contains a file named super_mario.dat”)

-        The concludes for me to

o   Either you have very domain specific strategy components (bluetooth manager, audio manager, node state manager) with domain specific interfaces

o   Or the customer specific backends need lots of customer specific connections into the domains to get the information needed for taking decisions and for transitioning to the states

-        My feeling is that the first of both approach promises more concrete outcomes directly usable. Of course, one could try to generalize the actual policy engine in the background and implement it with one and the same component for all specific use cases and domains (e.g. using https://01.org/murphy).

My two cents …

Best regards

Marko Hoyer
Software Group II (ADITG/SW2)

Tel. +49 5121 49 6948
From: genivi-projects [mailto:genivi-projects-bounces at lists.genivi.org] On Behalf Of Feuer, Magnus
Sent: Donnerstag, 16. März 2017 23:42
To: Zeeshan Ali
Cc: Genivi Project
Subject: Re: Policy Manager Project.


The project spawned from the question (shown in the ESOW) "which app gets the volume up press?". From there the system quickly evolved into a spec compliance monitor and a generic state machine / signal emitter.

We do not yet have a High-Level Description (HLD) since we are so early in the process. One of the purposes of running the project under GENIVI is to draw on the experience from the wider community as we explore the space, leading us to enough understanding to build the system correctly.

The deliverables, both the contractual bits and those provided out of contract by the community, allows us to experiment with signal management on GDP.

I think that the question we ultimately want to answer is if we can extract the business logic for signal routing, priority matrices, etc from the application / system code and move it to an external rule engine.

/Magnus F.

Head System Architect - Open Source Projects
Jaguar Land Rover

Email: mfeuer1 at jaguarlandrover.com<mailto:mfeuer1 at jaguarlandrover.com>
Mobile: +1 949 294 7871

[Image removed by sender.]
Jaguar Land Rover North America, LLC
1419 NW 14th Ave, Portland, OR 97209
Business Details:
Jaguar Land Rover Limited
Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
Registered in England No: 1672070

This e-mail and any attachments contain confidential information for a specific individual and purpose.  The information is private and privileged and intended solely for the use of the individual to whom it is addressed.  If you are not the intended recipient, please e-mail us immediately.  We apologise for any inconvenience caused but you are hereby notified that any disclosure, copying or distribution or the taking of any action in reliance on the information contained herein is strictly prohibited.

This e-mail does not constitute an order for goods or services unless accompanied by an official purchase order.

On Wed, Mar 15, 2017 at 4:44 AM, Zeeshan Ali <zeeshan.ali at pelagicore.com<mailto:zeeshan.ali at pelagicore.com>> wrote:
Hi Magnus,

On 15 March 2017 at 00:19, Feuer, Magnus <mfeuer1 at jaguarlandrover.com<mailto:mfeuer1 at jaguarlandrover.com>> wrote:
> Colleagues,
> JLR has sent out the attached Engineering Statement Of Work (ESOW) to select vendors. Our preference is to run this project as open source under the GENIVI umbrella with discussions and implementation being carried out in the open.

Really great to hear that you decided to develop this as open source
software and under GENIVI.

> With that in mind, we would very much appreciate feedback on the scope of the project and in which direction we can take this project in future phases. We are actively seeking participants in the community to contribute to the initial phase, adding weight to our case for open sourcing the project.

After a brief look at the SOW, I think one major thing missing in
there is the high-level description/introduction of the Policy
Manager. Could you please describe the project a bit?


Zeeshan Ali

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20170317/8992e2a5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: ~WRD000.jpg
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20170317/8992e2a5/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2016_03_17_Device-Management-Material_ADIT.pdf
Type: application/pdf
Size: 598699 bytes
Desc: 2016_03_17_Device-Management-Material_ADIT.pdf
URL: <http://lists.genivi.org/pipermail/genivi-projects_lists.genivi.org/attachments/20170317/8992e2a5/attachment.pdf>

More information about the genivi-projects mailing list