Merge pull request #29 from COVESA/explainer-fix

fixed broken VSS explainer link, added EU data act as example

VISS-explainer.md

@@ -1,25 +1,25 @@
 # VISS - Vehicle Information Service Specification Explainer
 
 Modern vehicles use hundreds of sensors which produce thousands of different data points, or signals, amounting to terabytes of data available per vehicle per day. The data points available on modern vehicles range from door lock state, fuel or charge level to tire pressure sensors and anti-lock brake control unit status. There is no question vehicles are transforming, becoming connected, electric and autonomous all of which relies extensively on signals data. 
-A common and standardized data model and interface would facilitate rapid innovation and development of various use cases involving this data.
+A common and standardized data model and interface facilitates rapid innovation and development of various use cases involving this data.
 
-At the center of this effort is a common data model for these vehicle signals, namely the Vehicle Signal Specification ([VSS](https://covesa.github.io/vehicle_signal_specification/)) which has its own [explainer](https://www.covesa.global/sites/default/files/COVESA%20Vehicle%20Signal%20Specification_060122.pdf). To access this data in a standardized way an effort to develop an interface was initially started by W3C in collaboration with COVESA and in 2024 was transferred fully to [COVESA](https://covesa.global), the Vehicle Information Service Specification (VISS). The service can reside either in the vehicle, or in the cloud. Client applications can also reside in the vehicle, cloud or running on a nomad device such as a smartphone. 
+At the center of this effort is a common data model for these vehicle signals, namely the Vehicle Signal Specification ([VSS](https://covesa.github.io/vehicle_signal_specification/)) which is explained here [explainer](https://covesa.global/vehicle-signal-specification/). To access this data in a standardized way an effort to develop an interface was initially started by W3C in collaboration with COVESA and in 2024 was transferred fully to [COVESA](https://covesa.global), the Vehicle Information Service Specification (VISS). The service can reside either in the vehicle, or in the cloud. Client applications can also reside in the vehicle, cloud or running on a nomad device such as a smartphone. 
 
 Vehicle signals, the definition and access to them, has historically been OEM proprietary. This has made it difficult for suppliers, commercial fleets, 
 tech companies, insurance companies, regulators and other interested parties to integrate across vehicle brands. Furthermore, since VISS and VSS are open standards their use will reduce cost, promote innovation, interoperability and facilitate third party software development.
 
-VSS uses a tree structure with well defined open definitions, but it also has the ability to be extended to handle new and /or proprietary signals if 
+VSS uses a tree structure with well-defined open definitions, but it also has the ability to be extended to handle new and /or proprietary signals if 
 needed. The [transport](https://raw.githack.com/COVESA/vehicle-information-service-specification/main/spec/VISSv2_Transport.html) and [access (API)](https://raw.githack.com/COVESA/vehicle-information-service-specification/main/spec/VISSv2_Core.html) together comprise the VISS version 2 specification, that includes HTTPS, MQTT, as well as Websockets which was the only 
 transport protocol supported in the [first version of VISS](https://www.w3.org/TR/vehicle-information-service/). The second and current version of VISS also includes a complete access control model, ability to support a consent model, and filtering techniques to better fit OEM requirements. 
 
-The intention is to use web technologies to facilitate development of applications with limited, trusted entities and not to make vehicles available for arbitrary connections over the web. Access to specific data points and use of the information is outside of the scope of this work. It is expected automotive manufacturers will govern which parties can run logic on or against vehicles, manage permissions, conduct security and legal/privacy audits. Regulators and courts, [Massachussets Right to Repair lawsuit as an example](https://www.natlawreview.com/article/automakers-lawsuit-opposing-updates-to-massachusetts-right-to-repair-law-lingers), will undoubtedly influence this as well. VISS was designed as a technical solution to be flexible in accomodating the future business ecosystem. The COVESA Security and Data Expert Groups along with the W3C Automotive Privacy Principles Community Group will likely produce formal best practices which will include security and privacy aspects.
+The intention is to use web technologies to facilitate development of applications with limited, trusted entities and not to make vehicles available for arbitrary connections over the web. Access to specific data points and use of the information is outside the scope of this work. It is expected automotive manufacturers will govern which parties can run logic on or against vehicles, manage permissions, conduct security and legal/privacy audits. Regulators and courts, [Massachussets Right to Repair lawsuit as an example](https://www.natlawreview.com/article/automakers-lawsuit-opposing-updates-to-massachusetts-right-to-repair-law-lingers) and the [EU data act](https://www.eu-data-act.com) will undoubtedly influence this as well. VISS was designed as a technical solution to be flexible in accomodating the future business ecosystem. The COVESA Security and Data Expert Groups formal best practices which will include security and privacy aspects.
 
 VISS version 1 deferred on access control to individual implementations and as mentioned only supported Websockets. Of the thousands of data points potentially available, a client application could subscribe to an allowed subset, and thus receive initial and updated values over time. The second version expanded on the filters available for Websocket and MQTT subscriptions and also allows for individual requests over these protocols and HTTPS of individual signals or if allowed a set of specified signals. For example, issuing a request to the node Vehicle.Drivetrain.Transmission would, if authorized, return all data available for a vehicle's transmission. 
 
 _Notes on implementation and use_
 
 VISS has known implementations by Volvo, BMW, JLR, Renesas, Bosch, Visteon, Geotab, AGL and Mitsubishi Electric to name a few. 
-The underlying data model VSS is seeing much wider adoption, eg within AWS Fleetwise, Blackberry Ivy as well as having accompanying ontology ([VSSo](https://www.w3.org/TR/vsso/)) and graph schema for machine learning and generating knowledge graphs, since its uses go far beyond a single API.
+The underlying data model VSS is seeing much wider adoption, e.g. within AWS Fleetwise, Blackberry Ivy as well as having accompanying ontology ([VSSo](https://www.w3.org/TR/vsso/)) and graph schema for machine learning and generating knowledge graphs, since its uses go far beyond a single API.
 
 A client application for example could reside on the vehicle itself on an on-board logic, telematics or head unit. From there it can authenticate itself against VISS and based on permissions granted for the specific application, can read or even write data to/from the vehicle. Applications may be user facing, providing information to operator or occupants or performing data sampling for analysis.