Hello, On Aug 4, 2011, at 2:21, Jeremiah Foster wrote: > On Wed, Aug 3, 2011 at 5:35 PM, Jussi Vänskä <[email protected]> wrote: > On 08/03/2011 06:01 PM, Jeremiah Foster wrote: >> Any comments? >> >> I would go with this type of API segments divided according to the level and >> ease of access: >> >> for all developers: >> - QtQuick signals and data models. >> >> So developers would only have access to "data models" and Qt Signals? Not >> the actual data structures themselves? This would seem to preclude talking >> to things like Diagnostic Log and Trace. Or the compositor. Or systemd, >> should that be used. > > yes, and I don't think that is a problem for a software in the category of > 'apps' > > It is because the most likely group developing 'apps' for a car is the car > maker themselves. So they will want access to more than just Qt signals and > slots. > >> for tier 1 developers >> - Qt API >> >> This excludes ECU to ECU communication. Tier 1's would likely never accept >> this. > > Nor will any legislator approve MeeGo based systems to be used in any sort of > safety critical or even safety aware systems. Crafting an API for automotive > control systems is not the issue here, as the software stack won't get > certificated for use in safety critical systems. > > Really? What gives you that impression? Ford uses SYNC from Microsoft, that > is on the road already. Do you feel MeeGo IVI is not intended to be a > commercial OS in a head unit? What is its niche then?
Ford SYNC is not about safety. I think you can forget about any safety critical-related things from MeeGo IVI. Getting information from the various bus is fine, but internode communication or talking to ECU won't certainly happen from the head-unit. I highly doubt that car manufacturers would allow this. Regards, -- Romain KUNTZ Toyota InfoTechnology Center [email protected] >> There are some questions about the viability of dbus in the automotive >> environment due to the fact that it is considered slow in comparison to >> other embedded IPC systems. > > such as? > > It's too slow. > >> This would also nicely handle the security issue as the dbus is already a >> system bus with established session control and safety features. >> Customisation is also possible from QML all the way down to the dbus for >> those who absolutely need it through the Qt dbus interface. SocketCAN which >> was discussed earlier could be revealed as a dbus object as could be done >> with any other additional vehicle bus. >> >> This would likely be extremely limiting and would hardly be sufficient for >> the automotive environment. A car is not a phone. > > sure thing but IVI is about infotainment systems not control systems. I think > you are slightly out of focus here. Most dashboard information devices are > actually quite close to smart phones. Navigation, speech controls, telephony, > BT hands-free, media player, radio ... Those are all functionalities found in > both targets, the cars and the smart phones. > > The head unit is going to use different networks, networks that are not found > in a cell phone, things like CAN, MOST, LIN, and potentially EAVB. You'll > never find those on a phone. Doing things like 'dead reckoning' and > calculating wheel ticks are a level more complex with regards to location > that a cell phone is likely to do. The use of containers, a RTOS, and perhaps > things like Monta Vista's Bare Metal Engine will likely also exist, at least > in some vehicles. > > All this type of functionality seems to me to point to the need to interact > with lower level mechanisms in the car, including potentially internode > communication and talking to the ECU. I think the levels of abstraction > you've proposed are just to high in the stack. > > Regards, > > Jeremiah > _______________________________________________ > MeeGo-ivi mailing list > [email protected] > http://lists.meego.com/listinfo/meego-ivi _______________________________________________ MeeGo-ivi mailing list [email protected] http://lists.meego.com/listinfo/meego-ivi
