- From: Junichi Hashimoto <xju-hashimoto@kddi.com>
- Date: Thu, 2 Jul 2015 20:38:16 +0900
- To: "Gavigan, Kevin" <kgavigan@jaguarlandrover.com>
- Cc: T Guild <ted@w3.org>, Junichi Hashimoto <ju-hashimoto@kddilabs.jp>, Kazuyuki Ashimura <ashimura@w3.org>, public-auto-privacy-security@w3.org, Adam Crofts <acrofts1@jaguarlandrover.com>, "Abramski, Adam M" <adam.m.abramski@intel.com>, Paul Boyes <pb@opencar.com>, Paul Sanderson <psander1@jaguarlandrover.com>, Lovene Bhatia <lbhatia@jaguarlandrover.com>, Peter Virk <pvirk1@jaguarlandrover.com>
Hi Kevin, Your point is data integrity. I agree that it will be important for IoT and vehicles. I'm bit confusing on the architecture we are discussing. Perhaps, we have different architecture in each mind. I'm imagining the same architecture as the figure in page 4 of [1]. Simply say: [car] - [ivi] - [internet], where [ivi] implements the Vehicle APIs and behaves as a web browser. While you are modeling [car] more precisely, and also considering native interfaces. So it would be: [sensor(s)] - [ADAS controller] - [os?] - [internet?] I guess, ADAS controller provides the API to [os?], and applications written in C++ using the API run on the [os?]. If so, web browser doesn't need any more. Am I misunderstanding you? [1] https://www.w3.org/auto/security/wiki/images/9/9f/Proposed_Collaborative_Work_Procedures_for_Security_%26_Privacy_Consideration.pdf Regards, Junichi On 15/07/1 19:22 , Gavigan, Kevin wrote: > Hi Junichi, > > The ADAS Controller is the name I've used for the on vehicle system > (ECU) that implements driver assistance on the vehicle: > > /ADAS Controller (vehicle *onboard *electronic control unit (ECU) that > is responsible for providing Advanced Driver Assistance)/ > / > / > Part of the context for the use cases is the assertion that for each of > us, our vehicles (owned or rented) will be a device within our Internet > of Things. So vehicles will need to communicate in a secure way with a > wide range of other entities in the IoT including:/ > / > > * Other vehicles > * People external to the vehicle (using mobile or fixed office/home > based devices) > * Cloud Services (e.g. traffic management systems) > * etc etc > > The second use case: > > /Use Case: Advanced Driver Assistance System (ADAS) Controller accepts > input from authorized external source(s)/ > > is an example of a vehicle receiving information from offboard sources > and somehow it needs to know what level of trust to give to data from > these sources. > > However, internally vehicles may be implemented as a set of disparate, > discrete systems. For example, the electrical systems that support > operation of the Powertrain may have either no or minimal data links to > the systems that manage climate control that are on a different internal > (e.g. Controller Area Network (CAN)) bus. > > So one of the challenges faced by OEMs implementing the Vehicle and Data > Specs is that a particular signal might be available on a particular CAN > (or other) bus but not available at a different position on the vehicle > where another Electronic Controller Unit (ECU) or offboard modem (on a > different bus) needs to consume or expose that signal. > > Over time, some OEMs might choose to implement the Vehicle & Data APIs > and use them for secure communications between sub-systems within the > vehicle. This may reduce development effort, especially if those systems > need to be able to accept inputs from other onboard sources or external > sources based on the Vehicle and Data API anyway. > > The first and third use cases are ones that illustrate that onboard > systems need to authenticate where a message is coming from and trust > its source (and these could be other on vehicle systems as well as > external sources): > > /Use Case: Advanced Driver Assistance System (ADAS) Controller accepts > input from authorized onboard sensors/ > /Use Case: Advanced Driver Assistance System (ADAS) Controller sets > safety critical controls when driving vehicle/ > > [For completess, whilst its likely that OEMs would expose (parts of) the > Vehicle and Data API using Web technologies (JavaScript, JSON, RESTFul > services etc), onboard sharing of data could follow the specification > but using interfaces defined for implementation in C++, Java or C# etc.] > > Hope the above answers the question and is is helpful > > Regards, > > Kevin > > > > *Kevin Gavigan BSc (Hons), MSc, PhD, MCP MCTS* > */Software Architect/* > */Connected Infotainment > /* > > */Mobile: 07990 084866 > /* > /*Email:*/ kgavigan@jaguarlandrover.com > <mailto:kgavigan@jaguarlandrover.com> > > */Office address:/* > *GO03/057** • **Building 523, **Gaydon** • **Maildrop: (G03)**/ > /**Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR* > > On 1 July 2015 at 01:33, Junichi Hashimoto <xju-hashimoto@kddi.com > <mailto:xju-hashimoto@kddi.com>> wrote: > > Hi Kevin, > > Thank you for your work! > > I have a question on ADAS. Do you expect ADAS is developed as a WebApp? > Otherwise, how does it communicate with webruntime? > > Regards, > Junichi > > On 15/06/30 20:31 , Gavigan, Kevin wrote: > > Hi Ted and Junichi, > > /Re: Security and Privacy Task Force - Use Cases/ > > Just a quick email to say that I've linked in the new page and > added a > number of automotive security use cases to it. > > Please see: https://www.w3..org/auto/security/wiki/ASP_TF > <https://www.w3.org/auto/security/wiki/ASP_TF>, click on 'Use > Cases', > 'List of Use Cases' which shows: > > https://www.w3.org/auto/security/wiki/Use_Cases > > Along with other members of the group, will plan to add to this > over time... > > Regards and best wishes, > > Kevin > > > > *Kevin Gavigan BSc (Hons), MSc, PhD, MCP MCTS* > */Software Architect/* > */Connected Infotainment > /* > > */Mobile: 07990 084866 > /* > /*Email:*/ kgavigan@jaguarlandrover.com > <mailto:kgavigan@jaguarlandrover.com> > <mailto:kgavigan@jaguarlandrover.com > <mailto:kgavigan@jaguarlandrover.com>> > > */Office address:/* > *GO03/057** • **Building 523, **Gaydon** • **Maildrop: (G03)**/ > /**Jaguar Land Rover • Banbury Road • Gaydon • Warwick • CV35 0RR* > > > On 26 June 2015 at 19:02, Ted Guild <ted@w3.org > <mailto:ted@w3.org> <mailto:ted@w3.org <mailto:ted@w3.org>>> wrote: > > On Fri, 2015-06-26 at 16:46 +0100, Gavigan, Kevin wrote: > > Hi Ted and Junichi, > > > > > > >> we already agree with that you provides use cases. > Could you > > create a page and start writing them? > > > > > > Sorry for the slow response, its been hectic at work (a > couple of > > ~80hr weeks if you are allowed to count travelling :-). > > > > > > I've written up a number of use cases (in simple text > format at > > present), that I can upload, but have a newbie question: > > > > > > I can see how to edit the charter page, and from the Help > how to add > > links from that page to a new page, but can't see > how/where I can add > > a new 'Use Cases' page. Could you please advise? > > Hi Kevin, > > Sure. > > It isn't immediately intuitive but simply create a new URI > underneath > wiki/ > > https://www.w3.org/auto/security/wiki/Use_Cases > > If the page does not already exist you are given a link to > start it. > > [[There is currently no text in this page. You can search > for this page > title in other pages, search the related logs, or edit this > page. ]] > > You can start off with simply copy and pasting your text > file. The Help > pages can help you with formatting but here are a few basics: > > =Heading= > > Plain text goes here > > * list item 1 > * list item 2 > * list item 3 > > Sample link with text > > [http://www.w3.org/auto Auto activity homepage] > > ==Subheading=== > > You can click on edit of an existing page to see how the > formatting is > done on it. > > Cheers, > -- > Ted Guild <ted@w3.org <mailto:ted@w3.org> > <mailto:ted@w3.org <mailto:ted@w3.org>>> > W3C Systems Team > http://www.w3.org > > > >
Received on Thursday, 2 July 2015 11:48:55 UTC