Many thanks Ismo & Kevron for you feedback. Maybe now my question evolves to more a system architecture confusion...see below.
> -----Original Message----- > From: Puustinen, Ismo > Sent: Tuesday, April 01, 2014 4:31 PM > To: Counihan, Tom > Cc: [email protected] > Subject: Re: Understanding AMB dependencies on Murphy > > Hi, > > > To better understand this - can you elaborate on what influences these > > properties in Murphy? By that I mean what trigger events push each of > > these properties into their various states? > > For the two properties I mentioned, both do have algorithms for the > calculation > of the values from the basic properties. At the moment the algorithms are > simple -- NightMode, for instance, is calculated based on an exterior > brightness > threshold value. However, in finalized products, the algorithm can be much > more complex. For example NightMode needs some sort of hysteresis to > prevent oscillation of the mode in case the vehicle is driving under street > lighting or other variable lighting conditions. The algorithm may also take > into > account car interior lighting and possibly even vehicle position and current > time. The use case of applying some dampener algo to a wildly oscillating raw event source makes sense. Where we apply that logic - AMB vs. Murphy is not clear to me. For example - the exact same logic applies to fuelInfo - the fuel tank sensor will oscillate wildly as the vehicle moves. So can you explain why NightMode is in Murphy and FuelInfo in AMB - where both at a logical level are just environmental sensors with a filter/algo applied? I confess openly my knowledge of the finer points of Murphy are limited. However when I study the material I come with a distinct vision of a policy manager. By policy manager, I mean subscription to events, analysis of these events changing a state machine, and as one moves states the execution of a policy. Audio takes the lead use case, but I see a vision to expand beyond this to other domains. None the less, I always understood the boundary of Murphy was to "enforce" policy - "Murphy is a resource policy daemon, designed to do cross domain policy decisions in a configurable way." [1] 'Murphy's mission is to follow and understand the current system state and then make decisions triggered by events" [2] Collation and reporting of events seems to my limited understanding seem to deviate from that mission. On the other hand, when I look at AMB, I see its design boundaries as "AMB is a framework for accessing vehicle information from an application without the application having to know the specific details of the vehicle's network." [3] The use of the term "Message Broker" invokes in my head the Message Broker pattern, which is a pattern to "for message validation, message transformation and message routing" [4] The transformation part is key here. I understand today from Kevron's mail that throttling and filtering is part of the core AMB feature. Is message transformation one of the primary design goals of AMB and by extension should AMB be responsible for controlling and reporting the NightMode property? I guess my fundamental question boils down to this - do we have a cyclical architectural dependency that needs addressing - i.e. moving what appears to be AMB logic out of Murphy into AMB? Warm Regards Tom. [1] https://01.org/murphy [2] http://www.slideshare.net/badaindonesia/tizen-ivi-rusty-lynch-intel-korea-linux-forum-2012 [3] https://wiki.tizen.org/wiki/Automotive_Message_Broker [4] http://en.wikipedia.org/wiki/Message_broker > > > Can you elaborate on the boot sequence order here? > > Will AMB be fully functional before Murphy awakes? > > > > An example - if I park my vehicle last night (NightMode = true), and I > > return in the morning at day-break, does Murphy need to be up and > > running, observe the correct Nightmode value, pass it to AMB, which > > then raises the state change for the HMI to correctly adjust the user > > backlighting experience ] > > AMB and Murphy startups are not depending of each other -- both components > will notice when one goes away and comes back up. Murphy will fetch the > properties it is interested in and tell AMB the current statuses of the > properties > it controls when it notices AMB coming back online. It goes without saying > that > if AMB is not running, no AMB properties can be delivered, and if Murphy is > not running, it cannot calculate values for the properties it controls. In > that > sense the dependency between the two components is very weak. > > > Finally - could you explain the concurrency model in AMB - I'd like to > > understand the threading model better, specifically around having > > multiple clients delivering inbound events at various frequencies, > > normalising these to a standard interface and then potentially > > delivering these to various consumers... > > I haven't looked into these parts of AMB code, so I can't really comment on > this. > > -- > Ismo Puustinen <[email protected]> -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
