On Wed, Apr 2, 2014 at 5:53 AM, Counihan, Tom <[email protected]> wrote: > Thanks Ismo, continuing.... > >> -----Original Message----- >> From: Puustinen, Ismo >> Sent: Wednesday, April 02, 2014 12:38 PM >> To: Counihan, Tom >> Cc: [email protected] >> Subject: Re: Understanding AMB dependencies on Murphy >> >> Hi Tom! >> >> Thanks for the good questions you are presenting. It's good to come back to >> the >> design decisions every now and then to see if they are still valid. >> >> > 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. >> >> I think the difference here is the level of abstraction. The FuelInfo >> property is >> supposed to reflect as accurately as possible the amount of fuel in the >> system. >> No other "policy information" can change the amount of fuel present in the >> vehicle. NightMode, for instance, can be calculated using a complex >> heuristic, >> which can change based on vendor and user preferences. > > OEM's today apply a 'policy' to present a conservative final reading of fuel > tank measure - say "The system shall apply a policy of reporting 5% less than > actual tank volume", because the relationship between OEM and its > distribution channel is fraught with contractual obligations - i.e. and OEM > does not want to end up paying the 'seller' because an owner needs a road > pickup because the tank reading left the owner stranded. > > I know this is splitting hairs, but it comes down to 'what is the definition > of a 'policy'' > >> >> Consider, for instance, a vehicle where there is an interior lamp. >> Exterior brightness may change, but a case can be made that the NightMode >> should be off when the interior lamp is on because some screens are more >> readable that way. Murphy provides a place to configure that behavior, if >> some >> IVI vendor decides to implement it that way. > > I totally understand the example, but I still struggle to understand where > this logic is actually controlled. > For me I think it makes sense to collate and mangle this information as close > to the source of the information as possible. > The way I see this example is, both the exterior sensor and interior lamp > status come off the vehicle bus. > So we end up with AMB intercepting both raw events, sending across some IPC > to Murphy, which then amalgamates these events into a new property, then > sends it back down to AMB over IPC, which then in turn broadcasts that to > interested clients. > > Is my understanding of the message passing using our example here correct? > >> >> Another example: (hypothetical) laws in some country might say that user must >> not be distracted by bright screen when the time is past midnight. >> Creating that variant requires just changing the Murphy configuration file. > > This gets interesting now. By Time, let's assume that that is serviced by the > platform and not off the vehicle bus. > So, you have a scenario where you have multiple even source localities. > Murphy indeed today may have an easy way to handle this adaptive rule, but my > question is why would AMB not be the logical place that should execute > instead. It has a plugin mechanism, so could someone create a 'time' plugin > and deliver the info in there? > Is there a reason why AMB could not expand to strive to offer the same goal > of easily adaptability? > Essentially what you have is newProperty = f(event1, event2), where AMB could > have a sample f(), but offer a mechanism for that f() to be replaced in > production? >
One possible advantage murphy has over AMB is that murphy rules do not have to be compiled like AMB plugins. This is because Murphy uses lua scripting. I'm not sure if that feature is necessarily a game-changer though. I'm not sure how much system implementers will care whether or not they have to compile rules. And if it is a game-changer, AMB actually has a plugin that supports javascript scripting called "bluemonkey". So it is possible to write plugins that performs the same functions as Murphy does with NightMode, DrivingMode and probably others using javascript. >> >> Still one more example: user selects from a settings application that they >> want >> the NightMode to be off. Murphy is designed to interface different >> configuration settings. It catches the user command and promptly overrides >> the >> current NightMode setting. > > Again, this user invocation could be viewed as yet another event, where you > now have newProperty f(event1, event2, userEvent). > But it is more interesting - if the example of NightMode = [On|Off], what I > end up in this scenario with is AMB consuming CPU firing Event1 & 2 to > Murphy, it consumes cpu for it to essentially discard these events because > the user has overridden, to then pass back to AMB essentially a statically > configured value. > And I could conceivably end up with a scenario of handling a lot of traffic > with little system state information change. > We could end up in your example of event 1 & 2 being continually fired (I > could live with this if there were other clients interested in raw events), > but this firing will result everytime a repeated return trigger of the same > static property - NightMode = Off. > The performance argument is valid to me. Having higher-level policy decisions outside of AMB necessarily increases performance costs. > We could debate the finer points here of engineering a better solution here, > but I cannot help coming back to the concept that mangling events is better > done close to the source as possible. This example looks like a low pass > filter to me. > AMB allows for mangling of events in both ways (close to the source or via an external process like Murphy). Cost of moving from the current way of doing it via Murphy to doing it entirely inside an AMB source is fairly cheap. I would be interested in understanding how system integrators would prefer doing it. I think Tom is arguing that they would probably prefer keeping it closer to the source to avoid architecture design hops and possibly for performance reasons. I think there is some merit to these arguments. -Kevron >> >> For dampening, I think you might mean that the sensors providing the basic >> information should be dampened? > > Yes. > >> >> > 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. >> >> Well, Murphy is not state machine based as such -- it is rule based. >> When an event comes in, rules are run. But you are right in that one of >> Murphy's main goals is to be able to combine information coming from >> multiple domains for decision making. In the case that you are describing, >> AMB >> can be considered to be in "automotive domain". >> >> > 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. >> >> Hmm, I don't see it that way. The fact whether we are in night mode is, in >> this >> particular case, a policy decision that Murphy makes. The value is >> communicated back to AMB so that others can benefit from that information. I >> don't quite understand what you mean by "enforcing" in this case. > > My understanding of "enforcing" is inspired by: > http://www.slideshare.net/badaindonesia/tizen-ivi-rusty-lynch-intel-korea-linux-forum-2012 > slide 11. > And: > http://events.linuxfoundation.org/sites/events/files/slides/ALS-Murphy-2013-Edinburgh.pdf > Slide 4 - "Policy enforcement > * To make applications comply with the policies" > > I guess what I am struggling with here - using the NightMode as an example - > is NightMode really making applications comply with a policy, and if so what > is the policy. > I'm only seeing a property value change at the moment. > >> >> > 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? >> >> The message transformation in this sense means that the information coming >> from CAN bus is transformed into D-Bus or JSON messages. It doesn't mean >> that complex policy processing is done. From the "Message Broker" Wikipedia >> link you provided: "Transform messages to an alternative representation". >> This >> is exactly what AMB is doing. >> >> Throttling and filtering is an important (upcoming) feature in AMB, though. >> The >> best implementation might be if clients could push their own filters and >> throttles to AMB so that they could receive events on the speed of their own >> choosing. For instance, a speedometer might need speed events once per >> second, but some other application might want to be alerted only when the >> value went over some threshold. > > Agreed. > >> Murphy will most likely set its own filters and >> throttles at some point. > > Can you expand ? > >> >> > 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? >> >> So, in short: I think the way responsibilities are shared between AMB and >> Murphy is still a sound one. Both components are doing what they are supposed >> to do, and the dependency between the components is minimal. If Murphy is >> missing, AMB is just not receiving updates for those properties controlled by >> Murphy. If AMB is missing, Murphy is just not doing decisions that depend on >> automotive data. Let's not fix things that are not broken. > > I can concede that things may not be broken from a code perspective, but I'm > really struggling to come to the same conclusion on whether we are broken > from an architecture perspective. > > I hope you don't find my line of questioning too pedantic, perhaps I'm being > overly simplistic here, but where I see a cyclical dependency it immediate > triggers questions around architectural layering and hence my question here. > >> >> -- >> 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 _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
