https://www.digitalplaybook.org/api.php?action=feedcontributions&user=Admin&feedformat=atomdigitalplaybook.org - User contributions [en]2024-03-29T14:05:18ZUser contributionsMediaWiki 1.39.0https://www.digitalplaybook.org/index.php?title=DTA05_-_Industrial_Internet_and_Artificial_Intelligence_of_Things&diff=8188DTA05 - Industrial Internet and Artificial Intelligence of Things2023-07-09T18:32:48Z<p>Admin: /* Day 1 */</p>
<hr />
<div>=Overview=<br />
[[File:From Industrial Internet towards the Artificial Intelligence of Things.png|700px|frameless|center|Group Execrcise]]<br />
==Day 1==<br />
{| class="wikitable"<br />
|+ DTA05 - Day 1 (Monday)<br />
|-<br />
! Time !! Title !! Description<br />
|-<br />
| 08:30 - 09:30 || Introduction || Welcome, introduction of participants<br />
|-<br />
| || || From [https://ec.europa.eu/futurium/en/system/files/ged/a2-schweichhart-reference_architectural_model_industrie_4.0_rami_4.0.pdf I4.0] and [https://www.iiconsortium.org/iira/ Industrial Internet] towards the Artificial Intelligence of Things<br />
|-<br />
| || || AIoT and the Digital Playbook<br />
|-<br />
| || || Overview of course, introduction of learning goals<br />
|-<br />
| 09:30 - 10:00 || Break ||<br />
|-<br />
| 10:00 - 11:00 || [[Business_Strategy|Business Strategy]] || Strategies for Digital OEMS, Digital Equipment Operators and Hybrid Models<br />
|-<br />
| 11:00 - 11:15 || Break ||<br />
|-<br />
| 11:15 - 12:15 || [[AIoT_101|AIoT 101]] || Industrial Internet 101, Hardware 101<br />
|-<br />
| || || AI 101, Data 101, Digital Twin 101<br />
|-<br />
| 12:15 - 13:15 || Lunch ||<br />
|-<br />
| 13:15 - 14:15 || [[Business_Execution|Business Execution]] || Business Model Design<br />
|-<br />
| 14:15 - 14:45 || Break||<br />
|-<br />
| 14:45 - 16:15 || Group Exercise I || Set up teams, discuss task, break out into groups<br />
|-<br />
| 16:15 - 16:30 || Break||<br />
|-<br />
| 16:30 - 17:30 || Group Exercise I || Review results<br />
|}<br />
<br />
[[File:Masterclass Overview.png|800px|frameless|center|Masterclass Overview]]<br />
<br />
==Day 2==<br />
{| class="wikitable"<br />
|+ DTA05 - Day 2 (Tuesday)<br />
|-<br />
! Time !! Title !! Description<br />
|-<br />
| 08:30 - 09:30 || Welcome Back || Recap from day 1 & Learnng goals day 2<br />
|-<br />
| || Technical Execution || AI.exe, Data.exe, DigitalTwin.exe, IoT.exe, Hardware.exe<br />
|-<br />
| 09:30 - 10:00 || Break ||<br />
|-<br />
| 10:00 - 11:00 || [http://Product_Architecture AIoT System Design] || Creating the system design, including business, usage, data/functional, <br />
|-<br />
| || ||implementation and product viewpoints<br />
|-<br />
| 11:00 - 11:15 || Break ||<br />
|-<br />
| 11:15 - 12:00 || AIoT Organization || Setting up the AIoT Organization<br />
|-<br />
| 12:00 - 13:00 || Lunch ||<br />
|-<br />
| 13:00 - 14:15 || Pneumatics system demo || demo kit presentation<br />
|-<br />
| || Discussion || <br />
|-<br />
| 14:15 - 14:45 || Break||<br />
|-<br />
| 14:45 - 16:15 || Group Exercise II || Set up teams, discuss task, break out into groups<br />
|-<br />
| 16:15 - 16:30 || Break||<br />
|-<br />
| 16:30 - 17:30 || Group Exercise II || Review results<br />
|}<br />
<br />
==Day 3==<br />
{| class="wikitable"<br />
|+ DTA05 - Day 3 (Wednesday)<br />
|-<br />
! Time !! Title !! Description<br />
|-<br />
| 08:30 - 09:30 || Welcome Back || Recap from day 2 & Learnng goals day 3<br />
|-<br />
| || AIoT Sourcing || Sourcing strategies and procurement for AIoT<br />
|-<br />
| || Discussion || <br />
|-<br />
| 09:30 - 10:00 || Break ||<br />
|-<br />
| 10:00 - 11:30 || Group Exercise III || Create an AIoT sourcing strategy in your group<br />
|-<br />
| 11:30 - 11:45 || Break ||<br />
|-<br />
| 11:45 - 12:30 || Results Review || Joint review the results of the group exercise <br />
|-<br />
| 12:30 - 13:30 || Lunch ||<br />
|-<br />
| 13:30 - 15:00 || AIoT DevOps & Co || Agile AIoT ^ AIoT DevOps<br />
|-<br />
| || || Robustness & Quality, Verification & Validation, Resilience & Reliability <br />
|-<br />
| || || Finally: Service Operations<br />
|-<br />
| || Discussion || <br />
|-<br />
| 15:00 - 15:30 || Break ||<br />
|-<br />
| 15:30 - 16:30 || Wrap-up || Wrap up<br />
|-<br />
| || || Outlook: Co-creation & AIoT Transformation Programs <br />
|-<br />
| 16:30 - 16:45 || Break ||<br />
|-<br />
| 16:45 - 17:30 || Question & Answer || <br />
|}<br />
<br />
==Day 4==<br />
{| class="wikitable"<br />
|+ DTA05 - Day 4 (Thursday)<br />
|-<br />
! Time !! Title !! Description<br />
|-<br />
| 08:30 - 09:15 || Technical Deep Dive || AIoT applied to automotive [https://landing.ai/ Landing.AI] platform and [https://digitalauto.netlify.app/ digital.auto Playground] usage guidance <br />
|-<br />
| 09:15 - 09:30 || Break & Team up ||<br />
|-<br />
| 09:30 - 12:30 || Practice || AIoT prototyping with Landing.AI platform and digital.auto Playground<br />
|-<br />
| 12:30 - 13:30 || Lunch ||<br />
|-<br />
| 13:30 - 14:30 || Practice results review || <br />
|-<br />
| 14:30 - 14:45 || Break || <br />
|-<br />
| 14:45 - 15:45 || AIoT Lab || [[Home: digital.auto|digital.auto]] projects introduction <br />
|-<br />
| 15:45 - 16:15 || Break ||<br />
|-<br />
| 16:15 - 16:30 || Exam Instructions || <br />
|-<br />
| 16:30 - 17:30 || Writting Exam || 1-hour open-book exam<br />
|}<br />
<br />
==Group Exercise==<br />
[[File:Industrial Internet Landing Page.png|300px|frameless|center|Group Execrcise]]<br />
==== Miro Boards for Industrial Internet Group Exercises ====<br />
* Team 1: [https://miro.com/app/board/uXjVM6F3fx8=/?share_link_id=817284982332 Link]<br />
* Team 2: [https://miro.com/app/board/uXjVM6F3f3c=/?share%20link%20id=717283888392 Link]<br />
* Team 3: [https://miro.com/app/board/uXjVM6F3f1k=/?share%20link%20id=7025180570 Link]<br />
* Team 4: [https://miro.com/app/board/uXjVM6F3fpE=/?share_link_id=516123829716 Link]<br />
* Team 5: [https://miro.com/app/board/uXjVM6GJZkU=/?share_link_id=932998106854 Link]</div>Adminhttps://www.digitalplaybook.org/index.php?title=Artificial_Intelligence_101&diff=8098Artificial Intelligence 1012023-06-28T09:20:34Z<p>Admin: /* Deep Learning: Generative AI */</p>
<hr />
<div>__NOTOC__<br />
<imagemap><br />
File:0.2-AI 101.png|1200px|frameless|center|AI 101<br />
<br />
rect 4 4 1005 124 [[AIoT_101|More...]]<br />
rect 2737 266 3539 394 [[Data_101|More...]]<br />
rect 2737 128 3539 261 [[Artificial_Intelligence_101|More...]]<br />
rect 2737 394 3539 523 [[Digital_Twin_101|More...]]<br />
rect 2737 523 3539 655 [[Internet_of_Things_101|More...]]<br />
rect 2737 655 3534 788 [[AIoT Hardware|More...]]<br />
<br />
desc none<br />
</imagemap><br />
<br />
This section provides an Artificial Intelligence 101, including a basic overview, a summary of Supervised, Unsupervised and Reinforcement Learning, as well as Deep Learning and Artificial Neural Networks.<br />
<br />
__TOC__<br />
<br />
= Introduction =<br />
Artificial Intelligence (AI) is not a new concept. Over the last couple of decades, it has experienced several hype cycles, which alternated with phases of disillusionment and funding cuts ("AI winter"). The massive investments into AI by today's hyperscalers and other companies have significantly fueled the progress made with AI, with many practical applications now being deployed. <br />
<br />
A highly visible break-through event was the development of AlphaGo (developed by DeepMind Technologies, which was later acquired by Google), which in 2015 became the first computer Go program to beat a human professional Go player without handicap on a full-sized 19×19 Go board. Until then, Go was thought of as being "too deep" for a computer to master on the professional level. AlphaGo uses a combination of machine learning and tree search techniques.<br />
<br />
Many modern AI methods are based on advanced statistical methods. However, finding a commonly accepted definition of AI is not easy. A quip in [https://en.wikipedia.org/wiki/AI_effect Tesler's Theorem] says ''"AI is whatever hasn't been done yet"''. As computers are becoming increasingly capable, tasks previously considered to require intelligence are later often removed from the definition of AI. The traditional problems of AI research include reasoning, knowledge representation, planning, learning, natural language processing, perception, and the ability to move and manipulate objects <ref name="russel" />.<br />
<br />
Most likely the currently most relevant AI method is Machine Learning (ML). ML refers to a set of algorithms that improve automatically through experience and by the use of data<ref name="mitchell" />. Within ML, an important category is Deep Learning (DL), which utilizes so called ''multi-layered neural networks''. Deep Learning includes Deep Neural Networks (DNNs) and Convolutional Neural Networks (CNNs), amongst others. See below for an example of a CNN. <br />
<br />
The three most common ML methods include Supervised, Unsupervised and Reinforcement Learning. The Supervised Learning method relies on manually labeled sample data, which are used to train a model so that it can then be applied to similar, but new and unlabeled data. The unsupervised method attempts to automatically detect structures and patterns in data. With reinforcement learning, a trial and error approach is combined with rewards or penalties. Each method is discussed in more detail in the following sections. Some of the key concepts common to these ML methods are summarized in the table following.<br />
<br />
[[File:1.2-AI Definitions.png|800px|frameless|center|link=|Key AI Terms and Definitions]]<br />
<br />
= Supervised Learning =<br />
The first AI/ML method we want to look at is Supervised Learning. Supervised Learning requires a data set with some observations (e.g., images) and the labels of the observations (e.g., classes of objects on these images, such as "traffic light", "pedestrian", "speed limit", etc.).<br />
<br />
[[File:1.2-Supervised Learning.png|800px|frameless|center|link=|Supervised Learning]]<br />
<br />
The models are trained on these labeled data sets, and can then be applied to previously unknown observations. The supervised learning algorithm produces an inference function to make predictions about new, unseen observations that are provided as input. The model can be improved further by comparing its actual output with the intended output: so-called "backward propagation" of errors.<br />
<br />
The two main types of supervised models are regression and classification:<br />
* Classification: The output variable is a category, e.g., "stop sign", "traffic light", etc.<br />
* Regression: The output variable is a real continuous value, e.g., electricity demand prediction<br />
<br />
Some widely used examples of supervised machine learning algorithms are: <br />
* Linear regression, mainly used for regression problems<br />
* Random forest, mainly used for classification and regression problems<br />
* Support vector machines, mainly used for classification problems<br />
<br />
= Unsupervised Learning =<br />
The next ML method is Unsupervised Learning, which is a type of algorithm that learns patterns from unlabeled data. The main goal is to uncover previously unknown patterns in data. Unsupervised Machine Learning is used when one has no data on desired outcomes. <br />
<br />
[[File:1.2-Unsupervised Learning.png|800px|frameless|center|link=|Unsupervised Learning]]<br />
<br />
Typical applications of Unsupervised Machine learning include the following:<br />
* Clustering: automatically split the data set into groups according to similarity (not always easy)<br />
* Anomaly detection: used to automatically discover unusual data points in a data set, e.g., to identify a problem with a physical asset or equipment.<br />
* Association mining: used to identify sets of items that frequently occur together in a data set, e.g., "people who buy X also tend to buy Y"<br />
* Latent variable models: commonly used for data preprocessing, e.g., reducing the number of features in a data set (dimensionality reduction)<br />
<br />
= Reinforcement Learning =<br />
The third common ML method is Reinforcement Learning (RL). In RL, a so-called Agent learns to achieve its goals in an uncertain, potentially complex environment. This can be, for example, a game-like situation, where the agent is deployed into a simulation where it receives rewards or penalties for the actions it performs. The goal of the agent is to maximize the total reward. <br />
<br />
[[File:1.2-Reinforcement Learning.png|800px|frameless|center|link=|Reinforcement Learning]]<br />
<br />
One main challenge in Reinforcement Learning is to create a suitable simulation environment. For example, the RL environment for training autonomous driving algorithms must realistically simulate situations such as braking and collisions. The benefit is that it is usually much cheaper to train the model in a simulated environment, rather than risking damage to real physical objects by using immature models. The challenge is then to transfer the model out of the training environment and into the real world.<br />
<br />
= Deep Learning and Artificial Neural Networks =<br />
A specialized area within Machine Learning are so-called Artificial Neutral Networks or ANNs (often simply called Neural Networks). ANNs are vaguely inspired by the neural networks that constitute biological brains. An ANN is represented by a collection of connected nodes called neurons. The connections are referred to as edges. Each edge can transmit signals to other neurons (similar to the synapses in the human brain). The receiving neuron processes the incoming signal, and then signals other neurons that are connected to it. Signals are numbers, which are computed by statistical functions.<br />
<br />
The relationship between neurons and edges is usually weighted, increasing or decreasing the strength of the signals. The weights can be adjusted as learning proceeds. Usually, neurons are aggregated into layers, where different layers perform different transformations on their input signals. Signals travel through these layers, potentially multiple times. The adjective "deep" in Deep Learning is referring to the use of multiple layers in these networks.<br />
<br />
A popular implementation of ANNs are Convolutional Neural Networks (CNNs), which are often used for processing visual and other two-dimensional data. Another example is Generative Adversarial Networks, where multiple networks compete with each other (e.g., in games).<br />
<br />
[[File:1.2-CNN.png|800px|frameless|center|link=|Example: Convolutional Neural Network]]<br />
<br />
The example shows a CNN and its multiple layers. It is used to classify areas of an input image into different categories such as "traffic light" or "stop sign". There are four main operations in this CNN:<br />
* Convolution: Extract features from the input image, preserving the spatial relationship between pixels by using small squares of input data. Convolution is a linear operation: it performs elementwise matrix multiplication and addition.<br />
* Non Linearity: ReLU (Rectified Linear Unit) is an operation applied after the convolution operations. ReLU introduces non-linearity in the CNN, which is important because most real-world data are non-linear.<br />
* Spatial Pooling/down-sampling: This step reduces the dimensionality of each feature map, while retaining the most important information.<br />
* Classification (Fully Connected Layer): The outputs from the first three layers are high-level features of the input image. The Fully Connected Layer uses these features to classify the input image into various classes based on the training dataset.<br />
<br />
A more detailed explanation of a similar example is provided by Ujjwal Karn on [https://www.kdnuggets.com/2016/11/intuitive-explanation-convolutional-neural-networks.html KDNuggets].<br />
<br />
= Deep Learning: Generative AI =<br />
Generative AI is a subset of Deep Learning. It is a type of Artificial intelligence that creates new content based on what it has learned from existing content. The learning process is abstracting the data probability distributions by training large-scale datasets, and after that, it produces a statistical model. Users are usually interacting with a Generative AI via a so-call prompt, for example a question asked to the system. The prompt can include specifics like information on how the answer should be structured, e.g. number of words to be generated.<br />
<br />
Through the given prompts, the generative AI utilizes the statistical model to forecast the expected response, generating new content.<br />
<br />
Generative models can be divided into two types: generative language models and generative image/video models.<br />
<br />
Generative language models are based on Natural Language Processing (NLP) techniques to generate new text by learning the laws and patterns of a given language. They usually have billions or larger orders of magnitude of parameters by training based on large-scale textual data like news, articles, novels, or web content, also called Large Language Models (LLMs). Examples for currently popular LLMs are GPT-3 and GPT-4 (OpenAI / ChatGTP), LaMDA (Google Bard), and LLaMA. <br />
<br />
The fundamental concept behind these LLMs relies on a deep learning model known as the "Transformer" architecture. During model training, LLMs encode each word in the input text and convert it into a vector representation called Word Embedding. The "Transformer" architecture uses an attention mechanism to better understand the correlation between different Word Embeddings and can effectively handle long text dependencies. Through this mechanism, LLMs can infer the correct context in the training task to predict the next word's probability distribution accurately. In a real-world application, such as a Chatbot, it will first convert the user input into a complete sequence of text and then feed it to LLMs, which will use the previous words to predict the next one until a complete response is generated.<br />
<br />
Generative image models are based on Computer Vision (CV) technique that generate new images by learning the features and structure of the existing images. The more classical model is the generative adversarial network (GAN) -- it comprises a generator that produces fake images and a discriminator that distinguishes between real and fake images, with both networks competing to generate realistic images through iterative iterations. Diffusion Models has received extensive attention in 2023, most strikingly for its excellent performance on the text-to-Image task. It passes randomly sampled Gaussian noise into the model and then generates data by learning the denoising process. The performance of OpenAI's DALL-E 2, Google Brain's Imagen, and StabilityAI's Stable Diffusion are approaching the quality of real photographs and human-drawn art.<br />
<br />
Generative AI has a large market in text (General writing, Note-taking, Marketing, Sales, Support, etc.), code (code generation, code documentation, text to SQL, web application builders, etc.), images (Image generation Media Advertising, Design, etc.), speech, video, 3D, and more.<br />
<br />
= Summary: AI & Data Analytics =<br />
The field of data analytics has evolved over the past decades, and is much broader than just AI and data science - so it is important to understand where AI/ML is fitting in. From the point of view of most AIoT use cases, there are four main types of analytics: descriptive, diagnostic, predictive and prescriptive analytics. Descriptive analytics is the most basic one, using mostly visual analytics to address the question ''"What happened?"''. Diagnostic analytics utilizes data mining techniques to answer the question ''"Why did it happen?"'', providing some king of root cause analysis. Data mining is the starting point of data science, with its own specific methods, processes, platforms and algorithms. AI - predominantly ML - often addresses the questions ''"What is likely to happen?"'' and ''"What to do about it?"''. Predictive analytics provides forecasts and predictions. Prescriptive analytics can be utilized, for example, to obtain detailed recommendations as work instructions, or even to enable closed-loop automation.<br />
[[File:00 Analytics.png|800px|frameless|center|link=|Analytics]]<br />
<br />
= References =<br />
<br />
<references><br />
<ref name="russel">Russell, Stuart J.; Norvig, Peter (2003), Artificial Intelligence: A Modern Approach (2nd ed.), Upper Saddle River, New Jersey: Prentice Hall, ISBN 0-13-790395-2</ref><br />
<ref name="mitchell">Mitchell, Tom (1997). Machine Learning. New York: McGraw Hill. ISBN 0-07-042807-7. OCLC 36417892.</ref><br />
</references></div>Adminhttps://www.digitalplaybook.org/index.php?title=Artificial_Intelligence_101&diff=8097Artificial Intelligence 1012023-06-28T09:02:21Z<p>Admin: /* Deep Learning and Artificial Neural Networks */</p>
<hr />
<div>__NOTOC__<br />
<imagemap><br />
File:0.2-AI 101.png|1200px|frameless|center|AI 101<br />
<br />
rect 4 4 1005 124 [[AIoT_101|More...]]<br />
rect 2737 266 3539 394 [[Data_101|More...]]<br />
rect 2737 128 3539 261 [[Artificial_Intelligence_101|More...]]<br />
rect 2737 394 3539 523 [[Digital_Twin_101|More...]]<br />
rect 2737 523 3539 655 [[Internet_of_Things_101|More...]]<br />
rect 2737 655 3534 788 [[AIoT Hardware|More...]]<br />
<br />
desc none<br />
</imagemap><br />
<br />
This section provides an Artificial Intelligence 101, including a basic overview, a summary of Supervised, Unsupervised and Reinforcement Learning, as well as Deep Learning and Artificial Neural Networks.<br />
<br />
__TOC__<br />
<br />
= Introduction =<br />
Artificial Intelligence (AI) is not a new concept. Over the last couple of decades, it has experienced several hype cycles, which alternated with phases of disillusionment and funding cuts ("AI winter"). The massive investments into AI by today's hyperscalers and other companies have significantly fueled the progress made with AI, with many practical applications now being deployed. <br />
<br />
A highly visible break-through event was the development of AlphaGo (developed by DeepMind Technologies, which was later acquired by Google), which in 2015 became the first computer Go program to beat a human professional Go player without handicap on a full-sized 19×19 Go board. Until then, Go was thought of as being "too deep" for a computer to master on the professional level. AlphaGo uses a combination of machine learning and tree search techniques.<br />
<br />
Many modern AI methods are based on advanced statistical methods. However, finding a commonly accepted definition of AI is not easy. A quip in [https://en.wikipedia.org/wiki/AI_effect Tesler's Theorem] says ''"AI is whatever hasn't been done yet"''. As computers are becoming increasingly capable, tasks previously considered to require intelligence are later often removed from the definition of AI. The traditional problems of AI research include reasoning, knowledge representation, planning, learning, natural language processing, perception, and the ability to move and manipulate objects <ref name="russel" />.<br />
<br />
Most likely the currently most relevant AI method is Machine Learning (ML). ML refers to a set of algorithms that improve automatically through experience and by the use of data<ref name="mitchell" />. Within ML, an important category is Deep Learning (DL), which utilizes so called ''multi-layered neural networks''. Deep Learning includes Deep Neural Networks (DNNs) and Convolutional Neural Networks (CNNs), amongst others. See below for an example of a CNN. <br />
<br />
The three most common ML methods include Supervised, Unsupervised and Reinforcement Learning. The Supervised Learning method relies on manually labeled sample data, which are used to train a model so that it can then be applied to similar, but new and unlabeled data. The unsupervised method attempts to automatically detect structures and patterns in data. With reinforcement learning, a trial and error approach is combined with rewards or penalties. Each method is discussed in more detail in the following sections. Some of the key concepts common to these ML methods are summarized in the table following.<br />
<br />
[[File:1.2-AI Definitions.png|800px|frameless|center|link=|Key AI Terms and Definitions]]<br />
<br />
= Supervised Learning =<br />
The first AI/ML method we want to look at is Supervised Learning. Supervised Learning requires a data set with some observations (e.g., images) and the labels of the observations (e.g., classes of objects on these images, such as "traffic light", "pedestrian", "speed limit", etc.).<br />
<br />
[[File:1.2-Supervised Learning.png|800px|frameless|center|link=|Supervised Learning]]<br />
<br />
The models are trained on these labeled data sets, and can then be applied to previously unknown observations. The supervised learning algorithm produces an inference function to make predictions about new, unseen observations that are provided as input. The model can be improved further by comparing its actual output with the intended output: so-called "backward propagation" of errors.<br />
<br />
The two main types of supervised models are regression and classification:<br />
* Classification: The output variable is a category, e.g., "stop sign", "traffic light", etc.<br />
* Regression: The output variable is a real continuous value, e.g., electricity demand prediction<br />
<br />
Some widely used examples of supervised machine learning algorithms are: <br />
* Linear regression, mainly used for regression problems<br />
* Random forest, mainly used for classification and regression problems<br />
* Support vector machines, mainly used for classification problems<br />
<br />
= Unsupervised Learning =<br />
The next ML method is Unsupervised Learning, which is a type of algorithm that learns patterns from unlabeled data. The main goal is to uncover previously unknown patterns in data. Unsupervised Machine Learning is used when one has no data on desired outcomes. <br />
<br />
[[File:1.2-Unsupervised Learning.png|800px|frameless|center|link=|Unsupervised Learning]]<br />
<br />
Typical applications of Unsupervised Machine learning include the following:<br />
* Clustering: automatically split the data set into groups according to similarity (not always easy)<br />
* Anomaly detection: used to automatically discover unusual data points in a data set, e.g., to identify a problem with a physical asset or equipment.<br />
* Association mining: used to identify sets of items that frequently occur together in a data set, e.g., "people who buy X also tend to buy Y"<br />
* Latent variable models: commonly used for data preprocessing, e.g., reducing the number of features in a data set (dimensionality reduction)<br />
<br />
= Reinforcement Learning =<br />
The third common ML method is Reinforcement Learning (RL). In RL, a so-called Agent learns to achieve its goals in an uncertain, potentially complex environment. This can be, for example, a game-like situation, where the agent is deployed into a simulation where it receives rewards or penalties for the actions it performs. The goal of the agent is to maximize the total reward. <br />
<br />
[[File:1.2-Reinforcement Learning.png|800px|frameless|center|link=|Reinforcement Learning]]<br />
<br />
One main challenge in Reinforcement Learning is to create a suitable simulation environment. For example, the RL environment for training autonomous driving algorithms must realistically simulate situations such as braking and collisions. The benefit is that it is usually much cheaper to train the model in a simulated environment, rather than risking damage to real physical objects by using immature models. The challenge is then to transfer the model out of the training environment and into the real world.<br />
<br />
= Deep Learning and Artificial Neural Networks =<br />
A specialized area within Machine Learning are so-called Artificial Neutral Networks or ANNs (often simply called Neural Networks). ANNs are vaguely inspired by the neural networks that constitute biological brains. An ANN is represented by a collection of connected nodes called neurons. The connections are referred to as edges. Each edge can transmit signals to other neurons (similar to the synapses in the human brain). The receiving neuron processes the incoming signal, and then signals other neurons that are connected to it. Signals are numbers, which are computed by statistical functions.<br />
<br />
The relationship between neurons and edges is usually weighted, increasing or decreasing the strength of the signals. The weights can be adjusted as learning proceeds. Usually, neurons are aggregated into layers, where different layers perform different transformations on their input signals. Signals travel through these layers, potentially multiple times. The adjective "deep" in Deep Learning is referring to the use of multiple layers in these networks.<br />
<br />
A popular implementation of ANNs are Convolutional Neural Networks (CNNs), which are often used for processing visual and other two-dimensional data. Another example is Generative Adversarial Networks, where multiple networks compete with each other (e.g., in games).<br />
<br />
[[File:1.2-CNN.png|800px|frameless|center|link=|Example: Convolutional Neural Network]]<br />
<br />
The example shows a CNN and its multiple layers. It is used to classify areas of an input image into different categories such as "traffic light" or "stop sign". There are four main operations in this CNN:<br />
* Convolution: Extract features from the input image, preserving the spatial relationship between pixels by using small squares of input data. Convolution is a linear operation: it performs elementwise matrix multiplication and addition.<br />
* Non Linearity: ReLU (Rectified Linear Unit) is an operation applied after the convolution operations. ReLU introduces non-linearity in the CNN, which is important because most real-world data are non-linear.<br />
* Spatial Pooling/down-sampling: This step reduces the dimensionality of each feature map, while retaining the most important information.<br />
* Classification (Fully Connected Layer): The outputs from the first three layers are high-level features of the input image. The Fully Connected Layer uses these features to classify the input image into various classes based on the training dataset.<br />
<br />
A more detailed explanation of a similar example is provided by Ujjwal Karn on [https://www.kdnuggets.com/2016/11/intuitive-explanation-convolutional-neural-networks.html KDNuggets].<br />
<br />
= Deep Learning: Generative AI =<br />
TBD<br />
<br />
= Summary: AI & Data Analytics =<br />
The field of data analytics has evolved over the past decades, and is much broader than just AI and data science - so it is important to understand where AI/ML is fitting in. From the point of view of most AIoT use cases, there are four main types of analytics: descriptive, diagnostic, predictive and prescriptive analytics. Descriptive analytics is the most basic one, using mostly visual analytics to address the question ''"What happened?"''. Diagnostic analytics utilizes data mining techniques to answer the question ''"Why did it happen?"'', providing some king of root cause analysis. Data mining is the starting point of data science, with its own specific methods, processes, platforms and algorithms. AI - predominantly ML - often addresses the questions ''"What is likely to happen?"'' and ''"What to do about it?"''. Predictive analytics provides forecasts and predictions. Prescriptive analytics can be utilized, for example, to obtain detailed recommendations as work instructions, or even to enable closed-loop automation.<br />
[[File:00 Analytics.png|800px|frameless|center|link=|Analytics]]<br />
<br />
= References =<br />
<br />
<references><br />
<ref name="russel">Russell, Stuart J.; Norvig, Peter (2003), Artificial Intelligence: A Modern Approach (2nd ed.), Upper Saddle River, New Jersey: Prentice Hall, ISBN 0-13-790395-2</ref><br />
<ref name="mitchell">Mitchell, Tom (1997). Machine Learning. New York: McGraw Hill. ISBN 0-07-042807-7. OCLC 36417892.</ref><br />
</references></div>Adminhttps://www.digitalplaybook.org/index.php?title=DTA05_-_Industrial_Internet_and_Artificial_Intelligence_of_Things&diff=8096DTA05 - Industrial Internet and Artificial Intelligence of Things2023-06-28T08:54:44Z<p>Admin: /* Day 1 */</p>
<hr />
<div>=Overview=<br />
=Day 1=<br />
{| class="wikitable"<br />
|+ DTA05 - Day 1 (Monday)<br />
|-<br />
! Time !! Title !! Description<br />
|-<br />
| 08:30 - 09:15 || Introduction || Welcome, introduction of participants<br />
|-<br />
| || || From Industrial Internet towards the Artificial Intelligence of Things<br />
|-<br />
| || || AIoT and the Digital Playbook<br />
|-<br />
| || || Overview of course, introduction of learning goals<br />
|-<br />
| 09:15 - 09:30 || Break ||<br />
|-<br />
| 09:30 - 10:30 || [[Business_Strategy|Business Strategy]] || Strategies for Digital OEMS, Digital Equipment Operators and Hybrid Models<br />
|-<br />
| 10:30 - 10:45 || Break ||<br />
|-<br />
| 10:45 - 12:00 || [[AIoT_101|AIoT 101]] || Industrial Internet 101, Hardware 101<br />
|-<br />
| || || AI 101, Data 101, Digital Twin 101<br />
|-<br />
| 12:00 - 13:00 || Lunch ||<br />
|-<br />
| 13:00 - 14:00 || [[Business_Execution|Business Execution]] || Business Model Design<br />
|-<br />
| 14:00 - 14:30 || Break||<br />
|-<br />
| 14:30 - 16:00 || Group Exercise I || Set up teams, discuss task, break out into groups<br />
|-<br />
| 16:00 - 16:15 || Break||<br />
|-<br />
| 16:15 - 17:00 || Group Exercise I || Review results<br />
|}<br />
<br />
=Day 2=<br />
=Day 3=<br />
=Day 4=</div>Adminhttps://www.digitalplaybook.org/index.php?title=DTA05_-_Industrial_Internet_and_Artificial_Intelligence_of_Things&diff=8095DTA05 - Industrial Internet and Artificial Intelligence of Things2023-06-28T08:54:29Z<p>Admin: /* Day 1 */</p>
<hr />
<div>=Overview=<br />
=Day 1=<br />
{| class="wikitable"<br />
|+ DTA05 - Day 1 (Monday)<br />
|-<br />
! Time !! Title !! Description<br />
|-<br />
| 08:30 - 09:15 || Introduction || Welcome, introduction of participants<br />
|-<br />
| || || From Industrial Internet towards the Artificial Intelligence of Things<br />
|-<br />
| || || AIoT and the Digital Playbook<br />
|-<br />
| || || Overview of course, introduction of learning goals<br />
|-<br />
| 09:15 - 09:30 || Break ||<br />
|-<br />
| 09:30 - 10:30 || [[Business_Strategy Business Strategy]] || Strategies for Digital OEMS, Digital Equipment Operators and Hybrid Models<br />
|-<br />
| 10:30 - 10:45 || Break ||<br />
|-<br />
| 10:45 - 12:00 || [[AIoT_101|AIoT 101]] || Industrial Internet 101, Hardware 101<br />
|-<br />
| || || AI 101, Data 101, Digital Twin 101<br />
|-<br />
| 12:00 - 13:00 || Lunch ||<br />
|-<br />
| 13:00 - 14:00 || [[Business_Execution|Business Execution]] || Business Model Design<br />
|-<br />
| 14:00 - 14:30 || Break||<br />
|-<br />
| 14:30 - 16:00 || Group Exercise I || Set up teams, discuss task, break out into groups<br />
|-<br />
| 16:00 - 16:15 || Break||<br />
|-<br />
| 16:15 - 17:00 || Group Exercise I || Review results<br />
|}<br />
<br />
=Day 2=<br />
=Day 3=<br />
=Day 4=</div>Adminhttps://www.digitalplaybook.org/index.php?title=DTA05_-_Industrial_Internet_and_Artificial_Intelligence_of_Things&diff=8094DTA05 - Industrial Internet and Artificial Intelligence of Things2023-06-28T08:53:50Z<p>Admin: /* Day 1 */</p>
<hr />
<div>=Overview=<br />
=Day 1=<br />
{| class="wikitable"<br />
|+ DTA05 - Day 1 (Monday)<br />
|-<br />
! Time !! Title !! Description<br />
|-<br />
| 08:30 - 09:15 || Introduction || Welcome, introduction of participants<br />
|-<br />
| || || From Industrial Internet towards the Artificial Intelligence of Things<br />
|-<br />
| || || AIoT and the Digital Playbook<br />
|-<br />
| || || Overview of course, introduction of learning goals<br />
|-<br />
| 09:15 - 09:30 || Break ||<br />
|-<br />
| 09:30 - 10:30 || [http://Business_Strategy Business Strategy] || Strategies for Digital OEMS, Digital Equipment Operators and Hybrid Models<br />
|-<br />
| 10:30 - 10:45 || Break ||<br />
|-<br />
| 10:45 - 12:00 || [[AIoT_101|AIoT 101]] || Industrial Internet 101, Hardware 101<br />
|-<br />
| || || AI 101, Data 101, Digital Twin 101<br />
|-<br />
| 12:00 - 13:00 || Lunch ||<br />
|-<br />
| 13:00 - 14:00 || [[Business_Execution|Business Execution]] || Business Model Design<br />
|-<br />
| 14:00 - 14:30 || Break||<br />
|-<br />
| 14:30 - 16:00 || Group Exercise I || Set up teams, discuss task, break out into groups<br />
|-<br />
| 16:00 - 16:15 || Break||<br />
|-<br />
| 16:15 - 17:00 || Group Exercise I || Review results<br />
|}<br />
<br />
=Day 2=<br />
=Day 3=<br />
=Day 4=</div>Adminhttps://www.digitalplaybook.org/index.php?title=DTA05_-_Industrial_Internet_and_Artificial_Intelligence_of_Things&diff=8093DTA05 - Industrial Internet and Artificial Intelligence of Things2023-06-28T08:52:28Z<p>Admin: Created page with "=Overview= =Day 1= {| class="wikitable" |+ DTA05 - Day 1 (Monday) |- ! Time !! Title !! Description |- | 08:30 - 09:15 || Introduction || Welcome, introduction of participants | || || From Industrial Internet towards the Artificial Intelligence of Things | || || AIoT and the Digital Playbook | || || Overview of course, introduction of learning goals | 09:15 - 09:30 || Break || | 09:30..."</p>
<hr />
<div>=Overview=<br />
=Day 1=<br />
{| class="wikitable"<br />
|+ DTA05 - Day 1 (Monday)<br />
|-<br />
! Time !! Title !! Description<br />
|-<br />
| 08:30 - 09:15 || Introduction || Welcome, introduction of participants<br />
| || || From Industrial Internet towards the Artificial Intelligence of Things<br />
| || || AIoT and the Digital Playbook<br />
| || || Overview of course, introduction of learning goals<br />
| 09:15 - 09:30 || Break ||<br />
| 09:30 - 10:30 || [http://Business_Strategy Business Strategy] || Strategies for Digital OEMS, Digital Equipment Operators and Hybrid Models<br />
| 10:30 - 10:45 || Break ||<br />
| 10:45 - 12:00 || [[AIoT_101|AIoT 101]] || Industrial Internet 101, Hardware 101<br />
| || || AI 101, Data 101, Digital Twin 101<br />
| 12:00 - 13:00 || Lunch ||<br />
| 13:00 - 14:00 || [[Business_Execution|Business Execution]] || Business Model Design<br />
| 14:00 - 14:30 || Break||<br />
| 14:30 - 16:00 || Group Exercise I || Set up teams, discuss task, break out into groups<br />
| 16:00 - 16:15 || Break||<br />
| 16:15 - 17:00 || Group Exercise I || Review results<br />
|}<br />
<br />
=Day 2=<br />
=Day 3=<br />
=Day 4=</div>Adminhttps://www.digitalplaybook.org/index.php?title=Documentation:_playground.digital.auto&diff=8089Documentation: playground.digital.auto2023-06-19T10:40:32Z<p>Admin: </p>
<hr />
<div>[[File:Playground.png|2000px|frameless|center|playground.digital.auto]]<br />
<s data-category="DigitalAuto"></s><br />
<br />
This page provides an architectural overview of the digital.auto playground, a web-based, rapid prototyping environment for the Software-defined Vehicle with standardized vehicle APIs. Click [[Developer Journey for digital.auto playground|here]] for the documentation along the developer journey.<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
The digital.auto playground provides automotive software developers and product managers with an environment to rapidly develop prototypes for the Software-defined Vehicle (SdV). The environment is purely web-based. Prototypes are developed in Python. To interact with vehicle sensors and actuators, the COVESA [https://wiki.covesa.global/display/WIK4/VSS+-+Vehicle+Signal+Specification Vehicle Signal Specification (VSS)] is used. In the browser environment of the playground, the vehicle sensors and actuators are mocked, using simple test values. Access to VSS in Python is provided via the emerging VSS Python mapping, as defined by the [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas] project (part of [https://sdv.eclipse.org/ Eclipse SdV]). As we will discuss in the following, access to more sophisticated vehicle simulation environments or even real sensors and actuators is possible via a cloud bridge mechanism.<br />
<br />
Also, please check out the following additional resources:<br />
* [https://drive.google.com/file/d/1qYfakx6E592PWBtPzAc_m_LrmBsvaI9K/view?usp=share_link Overview video] of digital.auto playground<br />
* [https://drive.google.com/file/d/1Z-tv5COhmX-lQGtHMSUZWLuvv5PoFAFR/view?usp=share_link Introduction] to digital.auto playground plugin development<br />
* digital.auto playground [https://playground-plugins.netlify.app/ widget documentation]<br />
<br />
=The value of early prototyping=<br />
<br />
The digital.project is promoting a digital-first approach to vehicle development: Develop the vehicle software and applications as early as possible, instead of after the hardware and physical vehicle design. This approach has two main benefits: First, early customer feedback helps to learn which ideas have highest potential for customer value creation. This helps minimizing investments in unpopular features. Fine-tuning the customer journey design early is key for customer acceptance. Of course this does not mean that the software should not constantly be improved later on, even after the Start of Production. After all, this is why DevOps pipelines with OTA for remote vehicle updates are currently being established.<br />
<br />
Second, doing early prototyping also has many benefits from the development perspective: Having a functional mockup early on in the development cycle helps improving transparency between business/IT, across regional and organizational boundaries. If also helps to validate architecture decisions early on, as well as to have a consistent enterprise architecture across all features. Finally, being able to identify API requirements as early as possible is key, because providing an API which encapsulates hardware usually has a very long lead time. This is especially true for hardware and APIs coming from external suppliers.<br />
<br />
[[File:Value of early prototyping.png|800px|frameless|center|Value of early prototyping]]<br />
<br />
=digital.auto value streams=<br />
The following is looking at both, the digital and physical value stream in digital.auto, followed by a discussion of the evolution of code in the digital value stream.<br />
<br />
==Digital and physical value stream==<br />
The digital.auto playground is designed to support the general philosophy of digital.auto, which is assuming two distinct value streams, moving at different speeds: The physical and the digital value stream. These two value streams are de-coupled via a Hardware Abstraction Layer (HAL), which is encapsulating the complexities of vehicle physics, embedded systems, and bus systems. Software components developed in the digital value stream are accessing vehicle functions via well defined interfaces (e.g. VSS). This de-coupling allows components north and south of the API to be (more or less) seamlessly interchanged. For example, a prototype in the playground can first run against simple test values provided by VSS mock implementations in the playground. Next, one might plug in a real vehicle simulation, running south of the API, and providing a more realistic system behavior. Finally, the simulation will be replaced by hardware with real sensors and actuators - starting with a breadboard, and eventually the final vehicle. <br />
<br />
[[File:Value Streams.png|800px|frameless|center|Value Streams]]<br />
<br />
Similarly, north of the API, new SdV features can initially be developed in Python in the playground. Next, the SdV prototype code can be deployed to a professional development environment - as provided, for example, by [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas]. In this environment, the new SdV feature can first be tested in the cloud, before finally being deployed on a vehicle computer.<br />
<br />
==Code evolution in the digital value stream==<br />
<br />
In order for the SdV code not to break when moving from the playground to the real development environment, the VSS Python APIs are currently being standardized by the Eclipse community. This allows to migrate code more easily between different environments. For example, as described in the figure below, an SdV function might initially be implemented as a prototype in the digital.auto playground. After the initial customer validation, the decision is made to migrate the code from the prototyping environment to the professional development environment, including proper support for CI/CD. This can be done easily because of the standardization of the Python APIs. In fact, the next release of the playground will have built-in support to deploy into Eclipse Velocitas by creating a complete Velocitas project in GitHub, based on the initial prototype.<br />
<br />
[[File:Deployment and code evolution.png|450px|frameless|center|Deployment and code evolution]]<br />
<br />
One important note: Even if the final target language for the production system is not Python - but maybe C++ or Rust - having a Python prototype for early vehicle tests is extremely valuable, because it helps getting an end-to-end implementation done quickly, and stabilizing the APIs between the distributed components.<br />
<br />
= VSS Python API =<br />
<br />
The VSS API is organized in a strict tree hierarchy. The nodes of the VSS tree are called branches. The leaves in the tree are representing sensors, actuators, and attributes. An example for a sensor representation in VSS looks like this:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.IsBelted</code><br />
<br />
This VSS API or data point will return a boolean value, indicating whether the belt is engaged. Please note that the VSS API catalogue can be adapted for individual vehicle instances - for example, supporting vehicles with different numbers of seat rows.<br />
<br />
An example for an actuator in VSS is shown in the following:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline</code><br />
<br />
This API will control the seat z-axis depends on seat tilt.<br />
<br />
==get()/set() functions==<br />
<br />
Using the VSS API in Python is straight forward. For example, to get the current state of a seat belt, the following code can be used:<br />
<br />
<code><br />
from ACME_Car_EV_v01 import Vehicle<br><br />
vehicle = Vehicle()<br><br />
vehicle.Cabin.Seat.Row1.Pos1.IsBelted.get()<br><br />
</code><br />
<br />
The <code>get()</code> function will simply return the current state of the <code>IsBelted</code> sensor represented by the corresponding Python object in the digital.auto playground library.<br />
<br />
Not very surprisingly, to control an actuator, a <code>set()</code> API is provided in Pyhton, e.g.:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.set(25)<br />
</code><br />
<br />
However, as straight-forward as this code actually looks like, the logic behind it is not as straight forward - the reason being that this API is supposed to control a physical device, which might not react immediately to the request (or maybe not at all). From the [https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/sensor_actuator/ VSS specification]: ''“Actuators are used to control the desired value of a property. Some properties in a vehicle cannot change instantly. A typical example is position of a seat or a window. Reading a value of an actuator shall return the current actual value, e.g. the current position of the seat, rather than the wanted/desired position. A typical example could be if someone wants to change the position of a seat from 0 to 100. This can be changed by setting the corresponding actuator to 100. If the actuator is read directly after the set request it will still return 0 as it might take some seconds before the seat reaches the wanted position of 100. If the seat by some reason is blocked or cannot be moved due to safety reasons it might never reach the wanted position. It is up to the vehicle to decide how long time it shall try to reach the desired value and what to do if it needs to give up.”'' <br />
<br />
Even though <code>BackrestRecline</code> is encapsulating an actuator, its current value can be read using <code>get()</code>:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.get()<br />
</code><br />
<br />
However, as per the above discussing please note that it might not be 100% clear what the return value is actually indicating. Note that there is work going on at the moment to support APIs which differentiate between the actual value vs the intended value of an actuator.<br />
<br />
Finally, please also note that the current version of VSS used here is not supporting meta data in the API that could be used to support additional service level, including real-time requirements, request priorization, etc. This means that the SdV code using VSS currently is aiming at applications which are labeled as "QM", according to the [https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level ASIL] standard - meaning the code does not support any of the higher ASIL safety levels, such as ASIL A, B, C or D.<br />
<br />
== Event listeners ==<br />
When dealing with sensor data - even for mocked sensors - it can often make sense to use a more event-driven model, instead of constantly polling the sensor. To support this, the Python API for VSS is supporting a simple event-driven programming model. Using the <code>subscribe()</code> method, a callback function can be associated with a sensor. This function will be called every time a new value is available.<br />
<br />
In the following code sample, a new function <code>on_hood_is_open_changed</code> is defined, and then associated with <code>vehicle.Body.Hood.IsOpen</code> via the <code>subscribe()</code> method. After this, a mock wiper is turned on to MEDIUM speed. Next, the mock hood is opened. This will result in <code>on_hood_is_open_changed</code> being called, which in turn will turn the wipers off.<br />
<br />
<code><br />
def on_hood_is_open_changed(IsOpen: bool):<br />
if IsOpen:<br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.OFF)<br />
vehicle.Body.Hood.IsOpen.subscribe(on_hood_is_open_changed)<br><br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.MEDIUM)<br><br />
vehicle.Body.Hood.IsOpen.set(True)<br><br />
</code><br />
<br />
=Playground architecture=<br />
The following provides an overview of the playground architecture, as well as the key elements of the plugin concept.<br />
<br />
==Overview==<br />
The digital.auto playground is designed to allow execution of SdV Python code against the standard VSS Python API. The SdV Python code is executed in the browser, against a set of Python objects representing the VSS API. To ensure a good user experience, the playground also has to support easy manipulation of the HTML Document Object Model (DOM), as well as remote interaction with the cloud. Since most browser development is done in JavaScript these days, the playground supports a plug-in mechanism which is implemented in JavaScript. This means that the SdV Prototypes in Pyhton are really interacting with VSS objects which are implemented in JavaScript. This way, a vehicle mockup can easily be built using browser-native tools. The mechanism used here is a Python-to-JavaScript bridge, which is translating between the SdV functions in Python and the plug-ins in JavaScript. <br />
<br />
[[File:Playground Architecture.png|800px|frameless|center|Playground Architecture]]<br />
<br />
The playground is trying to maximize re-use. This is happening on two levels:<br />
* Widgets: Re-useable Java Script artefacts for visualization of *any* kind of sensor<br />
* Plug-Ins: Sensor-specific UI elements, i.e. they are mapping specific sensor values to generic widgets<br />
<br />
The figure below describes how to get from widget to plug-in and eventually to the creation of custom dashboards using specific plug-ins.<br />
<br />
[[File:DashboardConfig.png|800px|frameless|center|alt=From widget to dashboard with plug-ins|From widget to dashboard with plug-ins]]<br />
<br />
==Playground plugins==<br />
<br />
Plugins for the digital.auto playground are usually providing a mockup and a visualization of a specific vehicle feature, exposed via VSS. An example could be a Google maps plugin, which is visualizing the vehicle's current position by accessing <code>Vehicle.CurrentLocation</code>.<br />
<br />
A plugin can provide two things:<br />
* Widget which are providing the UX to visualize the behavior represented by one or more VSS APIs<br />
* Simulators which are implementing VSS APIs<br />
<br />
An SdV prototype that wants to make use of a plugin must do two things:<br />
* Import the plugin Python library<br />
* Configure the plugins used (especially the UX layout)<br />
<br />
Plugins can be combined in different ways. For example, an SdV prototype might import the Google maps plugin to visualize the vehicle`s position on a map, plus another plugin which is actually implementing <code>Vehicle.CurrentLocation</code>. Or, the UX and the VSS implementation might be combined in one plugin, depending on the design.<br />
<br />
[[File:Plugin Overview.png|800px|frameless|center|Plugin Overview]]<br />
<br />
The digital.auto project is aiming to build up a rich plug-in library over time.<br />
However, often it will be required to implement dedicated plugins for a specific prototype.<br />
To support this, the plugin mechanism in the playground is open, both for plugin consumption as well as provisioning.<br />
<br />
For the implementer of a plugin, the following provides more detailed instructions for doing so.<br />
<br />
==Simulators==<br />
By default, the VSS Python API is providing an implementation which provides a very basic functionality: the <code>get()</code> functions are returning the current value (initialized randomly). The <code>set()</code> functions are storing the value passed to them.<br />
<br />
Simulators are providing a way to change this functionality. They allow plug-in developers to implement more specific functions for a given VSS sensors, actuator, or attribute. For example, a get function could communicate with a remote service in the cloud to receive the current sensor value. This can be any cloud, assuming that Cross-Origin Resource Sharing (CORS) or an alternative mechanism is used.<br />
<br />
A simulator can also be combined with a widget, e.g. to visualize a new sensor value.<br />
<br />
==Widgets==<br />
Widgets can use the built-in grid area of the playground to visualize vehicle functions, or even provide an interactive experience - using standard browser functionality. The grid is divided into 5x2 grid cells. A widget can occupy 1 or more grid cells, always assuming a rectangular shape.<br />
<br />
The grid mechanism is designed as simple as possible (we wanted to avoid the complexities of a full-blown portal server), yet giving a lot of flexibility. Each widget is mapped to an iFrame, meaning that a widget can use all functionalities which an iFrame supports.<br />
<br />
When designing a widget, using the right size must be ensured. For example, the ideal size for a 2x1 box video in the grid would be: 1080x756<br />
<br />
It doesn't need to be exact, but<br />
* Any size smaller would need to be centered, with space on all sides.<br />
* Any size larger would appear the exact same, but would take more time to load.<br />
* Any change in ratio would mean extra space (either horizontally or vertically)<br />
<br />
==Default Widget Style==<br />
Ideally, different widgets should use a similar style, so that if multiple widgets from different source are combined, they provide a consistent use experience. To achieve this, digital.auto recommends the following:<br />
* Use the following font: https://www.w3schools.com/cssref/css_websafe_fonts.php<br />
* Use only the colors defined on the following table, plus black/white<br />
<br />
[[File:Digital.auto colors.png|800px|frameless|center|digital.auto colors]]<br />
<br />
= Using plugins=<br />
In order to use a plugin, it needs to be imported and configured. The configuration is necessary so that the playground understands which prototypes should be used, and how to map them to the playground`s grid-based widget layout. The following example is configuring the use of two plugins, InstrumentPanel and SmartPhone:<br />
<br />
<code><br />
[<br><br />
{<br><br />
"boxes": [2, 3],<br><br />
"plugin": "InstrumentPanel",<br><br />
"widget": "Speedometer"<br><br />
},<br><br />
{<br><br />
"boxes": [1],<br><br />
"plugin": "SmartPhone",<br><br />
"widget": "Image"<br><br />
}<br><br />
]<br></code><br />
<br />
In this example, SmartPhone will occupy the first position in the playground grid, the Instrument panel the 2nd and 3rd.<br />
<br />
In order now to use these plugins in Python, the SdV prototype has to import <code>plugins</code>, like in the following example:<br />
<br />
<code><br />
from ACME_Car_ICE_v01 import Vehicle<br><br />
import plugins<br><br />
<br />
plugins.SmartPhone.set_text("Added text to SmartPhone")<br><br />
<br />
vehicle = Vehicle()<br><br />
<br />
await vehicle.Cabin.InstrumentPanel.Status.set(f"TEXT IN InstrumentPanel")<br><br />
<br />
</code><br />
<br />
In this example, a text is added via a proprietary API to a the mockup of a Smart Phone. This is because a Smart Phone is not part of VSS.<br />
Next, a text is added to <code>Vehicle.Cabin.InstrumentPanel.Status</code>. In this case, <code>InstrumentPanel.Status</code> was added to the VSS API as a Wishlist-Item, because this could actually make sense from a VSS perspective.<br />
<br />
= Implementing plugins=<br />
A plugin is made up of a Python module with one default exported function, that takes two deconstructed object parameters: <code>widgets</code> and <code>simulator</code>. Both are described in the following:<br />
<br />
==Widgets==<br />
<code>widgets</code> has one method, <code>register</code> that allows you to register widgets that can used by all the prototypes in the model through the '''Widgets Config''':<br />
<br />
<code><br />
register(widget_name: string, onActivate: (container: Container) => undefined | WidgetDeactivateFunction) => undefined<br />
</code><br />
<br />
===Container===<br />
Container has 3 properties:<br />
<br />
{| class="wikitable"<br />
|-<br />
! # !! Argument !! Description<br />
|-<br />
| 1 || <code>injectHTML(html: string) => void</code>|| <code>injectHTML</code> is used to inject html in the box, essentially setting its <code>innerHTML</code>.<br />
|-<br />
| 2 || <code>injectNode(node: Node) => void</code> || <code>injectNode</code> is used to inject an HTML Node (element or fragment) in the box. This is usually needed for complex use cases that <code>injectHTML</code> can't be used for, like event listeners.<br />
|-<br />
| 3 || window || The window object of the container iframe.<br />
|}<br />
<br />
===WidgetDeactivateFunction() => void===<br />
The deactivate function is executed whenever a widget is removed from the grid. This is useful for clearing stuff such as<br />
intervals<br />
<br />
==Simulator==<br />
<code><br />
simulator(api: string, method: "get" | "set" | "subscribe", func: SimulatorModifier) => void<br />
</code><br />
<br />
<code>simulator</code> is a function that let's you override any VSS API's get , set and subscribe methods<br />
<br />
It accepts 3 parameters:<br />
# <code>api</code>: The name of the VSS API to override, for example: Vehicle.Body.Hood.IsOpen<br />
# <code>method</code>: The method to override, this can be only one of get, set, or subscribe.<br />
# <code>func</code>: The modifier that is run when the API method is called, of SimulatorModifier type<br />
<br />
<code>SimulatorModifer</code> is called with two deconstructed object parameters:<br />
# <code>args: any[]</code>: Array of arguments passed in the Python code to the method, converted to equivalent JS types.<br />
# <code>prevReturnValue: any</code>: The return value this method would return if the prevReturnValue is undefined.<br />
Multiple plugins can each attach multiple modifiers to a method, all these modifiers will be called in the same order they were<br />
attached.<br />
<br />
The return value of the previous modifier will be passed to <code>prevReturnValue</code>.<br />
<br />
==Widgets Config==<br />
The widgets config is a JSON array of <code>GridItem</code> objects specified in the code tab of the prototype.<br />
<br />
GridItem has 3 properties:<br />
# <code>boxes: number[]</code>: The boxes this grid item should occupy. Boxes must be adjacent (horizontally or vertically) and for<br />
now, a grid item can occupy a maximum of 2 boxes.<br />
# <code>plugin: string</code>: The name of the plugin for this widget. This is the plugin name specified when creating a plugin.<br />
# <code>widget: string</code>: The widget name. This is specified in the plugin code when registering a widget<br />
<br />
= Summary =<br />
The following provides an overview of all elements involved: A vehicle model in the playground includes one instance of a VSS catalogue (e.g. the YAML definition file with all the VSS definitions), n number of plugin implementations, and n number of SdV prototypes. <br />
<br />
The VSS catalogue can be extended to use VSS Wishlist items, defined ad-hoc by different prototypes. digital.auto and COVESA are currently working on a way to submit items from the VSS Wishlist to the COVESA process for standardization of VSS.<br />
<br />
Plugins are defining simulators and widgets. Widgets are providing the UX for simulators (defined in the same of other plugins). In the future, each plugin will be associated with one SdV prototype for documentation purposes, as well as for defining the VSS wishlist APIs which might be required by the plugin.<br />
<br />
SdV prototypes are using plugins. In order to use a plugin, the configuration will have to state where exactly the required widgets should be played on the prototype-specific version of the playground grid.<br />
<br />
[[File:All Playground Elements.png|800px|frameless|center|All Playground Elements]]</div>Adminhttps://www.digitalplaybook.org/index.php?title=Documentation:_playground.digital.auto&diff=8088Documentation: playground.digital.auto2023-06-19T10:39:45Z<p>Admin: </p>
<hr />
<div>[[File:Playground.png|2000px|frameless|center|playground.digital.auto]]<br />
<s data-category="DigitalAuto"></s><br />
<br />
This page provides an architectural overview of the digital.auto playground, a web-based, rapid prototyping environment for the Software-defined Vehicle with standardized vehicle APIs. Click [http://Developer%20Journey%20for%20digital.auto%20playground here] for the documentation along the developer journey.<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
The digital.auto playground provides automotive software developers and product managers with an environment to rapidly develop prototypes for the Software-defined Vehicle (SdV). The environment is purely web-based. Prototypes are developed in Python. To interact with vehicle sensors and actuators, the COVESA [https://wiki.covesa.global/display/WIK4/VSS+-+Vehicle+Signal+Specification Vehicle Signal Specification (VSS)] is used. In the browser environment of the playground, the vehicle sensors and actuators are mocked, using simple test values. Access to VSS in Python is provided via the emerging VSS Python mapping, as defined by the [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas] project (part of [https://sdv.eclipse.org/ Eclipse SdV]). As we will discuss in the following, access to more sophisticated vehicle simulation environments or even real sensors and actuators is possible via a cloud bridge mechanism.<br />
<br />
Also, please check out the following additional resources:<br />
* [https://drive.google.com/file/d/1qYfakx6E592PWBtPzAc_m_LrmBsvaI9K/view?usp=share_link Overview video] of digital.auto playground<br />
* [https://drive.google.com/file/d/1Z-tv5COhmX-lQGtHMSUZWLuvv5PoFAFR/view?usp=share_link Introduction] to digital.auto playground plugin development<br />
* digital.auto playground [https://playground-plugins.netlify.app/ widget documentation]<br />
<br />
=The value of early prototyping=<br />
<br />
The digital.project is promoting a digital-first approach to vehicle development: Develop the vehicle software and applications as early as possible, instead of after the hardware and physical vehicle design. This approach has two main benefits: First, early customer feedback helps to learn which ideas have highest potential for customer value creation. This helps minimizing investments in unpopular features. Fine-tuning the customer journey design early is key for customer acceptance. Of course this does not mean that the software should not constantly be improved later on, even after the Start of Production. After all, this is why DevOps pipelines with OTA for remote vehicle updates are currently being established.<br />
<br />
Second, doing early prototyping also has many benefits from the development perspective: Having a functional mockup early on in the development cycle helps improving transparency between business/IT, across regional and organizational boundaries. If also helps to validate architecture decisions early on, as well as to have a consistent enterprise architecture across all features. Finally, being able to identify API requirements as early as possible is key, because providing an API which encapsulates hardware usually has a very long lead time. This is especially true for hardware and APIs coming from external suppliers.<br />
<br />
[[File:Value of early prototyping.png|800px|frameless|center|Value of early prototyping]]<br />
<br />
=digital.auto value streams=<br />
The following is looking at both, the digital and physical value stream in digital.auto, followed by a discussion of the evolution of code in the digital value stream.<br />
<br />
==Digital and physical value stream==<br />
The digital.auto playground is designed to support the general philosophy of digital.auto, which is assuming two distinct value streams, moving at different speeds: The physical and the digital value stream. These two value streams are de-coupled via a Hardware Abstraction Layer (HAL), which is encapsulating the complexities of vehicle physics, embedded systems, and bus systems. Software components developed in the digital value stream are accessing vehicle functions via well defined interfaces (e.g. VSS). This de-coupling allows components north and south of the API to be (more or less) seamlessly interchanged. For example, a prototype in the playground can first run against simple test values provided by VSS mock implementations in the playground. Next, one might plug in a real vehicle simulation, running south of the API, and providing a more realistic system behavior. Finally, the simulation will be replaced by hardware with real sensors and actuators - starting with a breadboard, and eventually the final vehicle. <br />
<br />
[[File:Value Streams.png|800px|frameless|center|Value Streams]]<br />
<br />
Similarly, north of the API, new SdV features can initially be developed in Python in the playground. Next, the SdV prototype code can be deployed to a professional development environment - as provided, for example, by [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas]. In this environment, the new SdV feature can first be tested in the cloud, before finally being deployed on a vehicle computer.<br />
<br />
==Code evolution in the digital value stream==<br />
<br />
In order for the SdV code not to break when moving from the playground to the real development environment, the VSS Python APIs are currently being standardized by the Eclipse community. This allows to migrate code more easily between different environments. For example, as described in the figure below, an SdV function might initially be implemented as a prototype in the digital.auto playground. After the initial customer validation, the decision is made to migrate the code from the prototyping environment to the professional development environment, including proper support for CI/CD. This can be done easily because of the standardization of the Python APIs. In fact, the next release of the playground will have built-in support to deploy into Eclipse Velocitas by creating a complete Velocitas project in GitHub, based on the initial prototype.<br />
<br />
[[File:Deployment and code evolution.png|450px|frameless|center|Deployment and code evolution]]<br />
<br />
One important note: Even if the final target language for the production system is not Python - but maybe C++ or Rust - having a Python prototype for early vehicle tests is extremely valuable, because it helps getting an end-to-end implementation done quickly, and stabilizing the APIs between the distributed components.<br />
<br />
= VSS Python API =<br />
<br />
The VSS API is organized in a strict tree hierarchy. The nodes of the VSS tree are called branches. The leaves in the tree are representing sensors, actuators, and attributes. An example for a sensor representation in VSS looks like this:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.IsBelted</code><br />
<br />
This VSS API or data point will return a boolean value, indicating whether the belt is engaged. Please note that the VSS API catalogue can be adapted for individual vehicle instances - for example, supporting vehicles with different numbers of seat rows.<br />
<br />
An example for an actuator in VSS is shown in the following:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline</code><br />
<br />
This API will control the seat z-axis depends on seat tilt.<br />
<br />
==get()/set() functions==<br />
<br />
Using the VSS API in Python is straight forward. For example, to get the current state of a seat belt, the following code can be used:<br />
<br />
<code><br />
from ACME_Car_EV_v01 import Vehicle<br><br />
vehicle = Vehicle()<br><br />
vehicle.Cabin.Seat.Row1.Pos1.IsBelted.get()<br><br />
</code><br />
<br />
The <code>get()</code> function will simply return the current state of the <code>IsBelted</code> sensor represented by the corresponding Python object in the digital.auto playground library.<br />
<br />
Not very surprisingly, to control an actuator, a <code>set()</code> API is provided in Pyhton, e.g.:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.set(25)<br />
</code><br />
<br />
However, as straight-forward as this code actually looks like, the logic behind it is not as straight forward - the reason being that this API is supposed to control a physical device, which might not react immediately to the request (or maybe not at all). From the [https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/sensor_actuator/ VSS specification]: ''“Actuators are used to control the desired value of a property. Some properties in a vehicle cannot change instantly. A typical example is position of a seat or a window. Reading a value of an actuator shall return the current actual value, e.g. the current position of the seat, rather than the wanted/desired position. A typical example could be if someone wants to change the position of a seat from 0 to 100. This can be changed by setting the corresponding actuator to 100. If the actuator is read directly after the set request it will still return 0 as it might take some seconds before the seat reaches the wanted position of 100. If the seat by some reason is blocked or cannot be moved due to safety reasons it might never reach the wanted position. It is up to the vehicle to decide how long time it shall try to reach the desired value and what to do if it needs to give up.”'' <br />
<br />
Even though <code>BackrestRecline</code> is encapsulating an actuator, its current value can be read using <code>get()</code>:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.get()<br />
</code><br />
<br />
However, as per the above discussing please note that it might not be 100% clear what the return value is actually indicating. Note that there is work going on at the moment to support APIs which differentiate between the actual value vs the intended value of an actuator.<br />
<br />
Finally, please also note that the current version of VSS used here is not supporting meta data in the API that could be used to support additional service level, including real-time requirements, request priorization, etc. This means that the SdV code using VSS currently is aiming at applications which are labeled as "QM", according to the [https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level ASIL] standard - meaning the code does not support any of the higher ASIL safety levels, such as ASIL A, B, C or D.<br />
<br />
== Event listeners ==<br />
When dealing with sensor data - even for mocked sensors - it can often make sense to use a more event-driven model, instead of constantly polling the sensor. To support this, the Python API for VSS is supporting a simple event-driven programming model. Using the <code>subscribe()</code> method, a callback function can be associated with a sensor. This function will be called every time a new value is available.<br />
<br />
In the following code sample, a new function <code>on_hood_is_open_changed</code> is defined, and then associated with <code>vehicle.Body.Hood.IsOpen</code> via the <code>subscribe()</code> method. After this, a mock wiper is turned on to MEDIUM speed. Next, the mock hood is opened. This will result in <code>on_hood_is_open_changed</code> being called, which in turn will turn the wipers off.<br />
<br />
<code><br />
def on_hood_is_open_changed(IsOpen: bool):<br />
if IsOpen:<br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.OFF)<br />
vehicle.Body.Hood.IsOpen.subscribe(on_hood_is_open_changed)<br><br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.MEDIUM)<br><br />
vehicle.Body.Hood.IsOpen.set(True)<br><br />
</code><br />
<br />
=Playground architecture=<br />
The following provides an overview of the playground architecture, as well as the key elements of the plugin concept.<br />
<br />
==Overview==<br />
The digital.auto playground is designed to allow execution of SdV Python code against the standard VSS Python API. The SdV Python code is executed in the browser, against a set of Python objects representing the VSS API. To ensure a good user experience, the playground also has to support easy manipulation of the HTML Document Object Model (DOM), as well as remote interaction with the cloud. Since most browser development is done in JavaScript these days, the playground supports a plug-in mechanism which is implemented in JavaScript. This means that the SdV Prototypes in Pyhton are really interacting with VSS objects which are implemented in JavaScript. This way, a vehicle mockup can easily be built using browser-native tools. The mechanism used here is a Python-to-JavaScript bridge, which is translating between the SdV functions in Python and the plug-ins in JavaScript. <br />
<br />
[[File:Playground Architecture.png|800px|frameless|center|Playground Architecture]]<br />
<br />
The playground is trying to maximize re-use. This is happening on two levels:<br />
* Widgets: Re-useable Java Script artefacts for visualization of *any* kind of sensor<br />
* Plug-Ins: Sensor-specific UI elements, i.e. they are mapping specific sensor values to generic widgets<br />
<br />
The figure below describes how to get from widget to plug-in and eventually to the creation of custom dashboards using specific plug-ins.<br />
<br />
[[File:DashboardConfig.png|800px|frameless|center|alt=From widget to dashboard with plug-ins|From widget to dashboard with plug-ins]]<br />
<br />
==Playground plugins==<br />
<br />
Plugins for the digital.auto playground are usually providing a mockup and a visualization of a specific vehicle feature, exposed via VSS. An example could be a Google maps plugin, which is visualizing the vehicle's current position by accessing <code>Vehicle.CurrentLocation</code>.<br />
<br />
A plugin can provide two things:<br />
* Widget which are providing the UX to visualize the behavior represented by one or more VSS APIs<br />
* Simulators which are implementing VSS APIs<br />
<br />
An SdV prototype that wants to make use of a plugin must do two things:<br />
* Import the plugin Python library<br />
* Configure the plugins used (especially the UX layout)<br />
<br />
Plugins can be combined in different ways. For example, an SdV prototype might import the Google maps plugin to visualize the vehicle`s position on a map, plus another plugin which is actually implementing <code>Vehicle.CurrentLocation</code>. Or, the UX and the VSS implementation might be combined in one plugin, depending on the design.<br />
<br />
[[File:Plugin Overview.png|800px|frameless|center|Plugin Overview]]<br />
<br />
The digital.auto project is aiming to build up a rich plug-in library over time.<br />
However, often it will be required to implement dedicated plugins for a specific prototype.<br />
To support this, the plugin mechanism in the playground is open, both for plugin consumption as well as provisioning.<br />
<br />
For the implementer of a plugin, the following provides more detailed instructions for doing so.<br />
<br />
==Simulators==<br />
By default, the VSS Python API is providing an implementation which provides a very basic functionality: the <code>get()</code> functions are returning the current value (initialized randomly). The <code>set()</code> functions are storing the value passed to them.<br />
<br />
Simulators are providing a way to change this functionality. They allow plug-in developers to implement more specific functions for a given VSS sensors, actuator, or attribute. For example, a get function could communicate with a remote service in the cloud to receive the current sensor value. This can be any cloud, assuming that Cross-Origin Resource Sharing (CORS) or an alternative mechanism is used.<br />
<br />
A simulator can also be combined with a widget, e.g. to visualize a new sensor value.<br />
<br />
==Widgets==<br />
Widgets can use the built-in grid area of the playground to visualize vehicle functions, or even provide an interactive experience - using standard browser functionality. The grid is divided into 5x2 grid cells. A widget can occupy 1 or more grid cells, always assuming a rectangular shape.<br />
<br />
The grid mechanism is designed as simple as possible (we wanted to avoid the complexities of a full-blown portal server), yet giving a lot of flexibility. Each widget is mapped to an iFrame, meaning that a widget can use all functionalities which an iFrame supports.<br />
<br />
When designing a widget, using the right size must be ensured. For example, the ideal size for a 2x1 box video in the grid would be: 1080x756<br />
<br />
It doesn't need to be exact, but<br />
* Any size smaller would need to be centered, with space on all sides.<br />
* Any size larger would appear the exact same, but would take more time to load.<br />
* Any change in ratio would mean extra space (either horizontally or vertically)<br />
<br />
==Default Widget Style==<br />
Ideally, different widgets should use a similar style, so that if multiple widgets from different source are combined, they provide a consistent use experience. To achieve this, digital.auto recommends the following:<br />
* Use the following font: https://www.w3schools.com/cssref/css_websafe_fonts.php<br />
* Use only the colors defined on the following table, plus black/white<br />
<br />
[[File:Digital.auto colors.png|800px|frameless|center|digital.auto colors]]<br />
<br />
= Using plugins=<br />
In order to use a plugin, it needs to be imported and configured. The configuration is necessary so that the playground understands which prototypes should be used, and how to map them to the playground`s grid-based widget layout. The following example is configuring the use of two plugins, InstrumentPanel and SmartPhone:<br />
<br />
<code><br />
[<br><br />
{<br><br />
"boxes": [2, 3],<br><br />
"plugin": "InstrumentPanel",<br><br />
"widget": "Speedometer"<br><br />
},<br><br />
{<br><br />
"boxes": [1],<br><br />
"plugin": "SmartPhone",<br><br />
"widget": "Image"<br><br />
}<br><br />
]<br></code><br />
<br />
In this example, SmartPhone will occupy the first position in the playground grid, the Instrument panel the 2nd and 3rd.<br />
<br />
In order now to use these plugins in Python, the SdV prototype has to import <code>plugins</code>, like in the following example:<br />
<br />
<code><br />
from ACME_Car_ICE_v01 import Vehicle<br><br />
import plugins<br><br />
<br />
plugins.SmartPhone.set_text("Added text to SmartPhone")<br><br />
<br />
vehicle = Vehicle()<br><br />
<br />
await vehicle.Cabin.InstrumentPanel.Status.set(f"TEXT IN InstrumentPanel")<br><br />
<br />
</code><br />
<br />
In this example, a text is added via a proprietary API to a the mockup of a Smart Phone. This is because a Smart Phone is not part of VSS.<br />
Next, a text is added to <code>Vehicle.Cabin.InstrumentPanel.Status</code>. In this case, <code>InstrumentPanel.Status</code> was added to the VSS API as a Wishlist-Item, because this could actually make sense from a VSS perspective.<br />
<br />
= Implementing plugins=<br />
A plugin is made up of a Python module with one default exported function, that takes two deconstructed object parameters: <code>widgets</code> and <code>simulator</code>. Both are described in the following:<br />
<br />
==Widgets==<br />
<code>widgets</code> has one method, <code>register</code> that allows you to register widgets that can used by all the prototypes in the model through the '''Widgets Config''':<br />
<br />
<code><br />
register(widget_name: string, onActivate: (container: Container) => undefined | WidgetDeactivateFunction) => undefined<br />
</code><br />
<br />
===Container===<br />
Container has 3 properties:<br />
<br />
{| class="wikitable"<br />
|-<br />
! # !! Argument !! Description<br />
|-<br />
| 1 || <code>injectHTML(html: string) => void</code>|| <code>injectHTML</code> is used to inject html in the box, essentially setting its <code>innerHTML</code>.<br />
|-<br />
| 2 || <code>injectNode(node: Node) => void</code> || <code>injectNode</code> is used to inject an HTML Node (element or fragment) in the box. This is usually needed for complex use cases that <code>injectHTML</code> can't be used for, like event listeners.<br />
|-<br />
| 3 || window || The window object of the container iframe.<br />
|}<br />
<br />
===WidgetDeactivateFunction() => void===<br />
The deactivate function is executed whenever a widget is removed from the grid. This is useful for clearing stuff such as<br />
intervals<br />
<br />
==Simulator==<br />
<code><br />
simulator(api: string, method: "get" | "set" | "subscribe", func: SimulatorModifier) => void<br />
</code><br />
<br />
<code>simulator</code> is a function that let's you override any VSS API's get , set and subscribe methods<br />
<br />
It accepts 3 parameters:<br />
# <code>api</code>: The name of the VSS API to override, for example: Vehicle.Body.Hood.IsOpen<br />
# <code>method</code>: The method to override, this can be only one of get, set, or subscribe.<br />
# <code>func</code>: The modifier that is run when the API method is called, of SimulatorModifier type<br />
<br />
<code>SimulatorModifer</code> is called with two deconstructed object parameters:<br />
# <code>args: any[]</code>: Array of arguments passed in the Python code to the method, converted to equivalent JS types.<br />
# <code>prevReturnValue: any</code>: The return value this method would return if the prevReturnValue is undefined.<br />
Multiple plugins can each attach multiple modifiers to a method, all these modifiers will be called in the same order they were<br />
attached.<br />
<br />
The return value of the previous modifier will be passed to <code>prevReturnValue</code>.<br />
<br />
==Widgets Config==<br />
The widgets config is a JSON array of <code>GridItem</code> objects specified in the code tab of the prototype.<br />
<br />
GridItem has 3 properties:<br />
# <code>boxes: number[]</code>: The boxes this grid item should occupy. Boxes must be adjacent (horizontally or vertically) and for<br />
now, a grid item can occupy a maximum of 2 boxes.<br />
# <code>plugin: string</code>: The name of the plugin for this widget. This is the plugin name specified when creating a plugin.<br />
# <code>widget: string</code>: The widget name. This is specified in the plugin code when registering a widget<br />
<br />
= Summary =<br />
The following provides an overview of all elements involved: A vehicle model in the playground includes one instance of a VSS catalogue (e.g. the YAML definition file with all the VSS definitions), n number of plugin implementations, and n number of SdV prototypes. <br />
<br />
The VSS catalogue can be extended to use VSS Wishlist items, defined ad-hoc by different prototypes. digital.auto and COVESA are currently working on a way to submit items from the VSS Wishlist to the COVESA process for standardization of VSS.<br />
<br />
Plugins are defining simulators and widgets. Widgets are providing the UX for simulators (defined in the same of other plugins). In the future, each plugin will be associated with one SdV prototype for documentation purposes, as well as for defining the VSS wishlist APIs which might be required by the plugin.<br />
<br />
SdV prototypes are using plugins. In order to use a plugin, the configuration will have to state where exactly the required widgets should be played on the prototype-specific version of the playground grid.<br />
<br />
[[File:All Playground Elements.png|800px|frameless|center|All Playground Elements]]</div>Adminhttps://www.digitalplaybook.org/index.php?title=WikiMgmt&diff=7854WikiMgmt2023-03-15T03:09:49Z<p>Admin: Created page with "This is an internal page used for Wiki management and maintenance. =Important Links= TBD: * Documentation * Create Word PDF from TOC * Link Wiki page to LinkedIn page/post * ... =Open Tasks= Wiki backlog, with priorities: short, medium, long term ==Short Term== Short term tasks: * Finalize installation/customization of Minerva ** Use as default for anonymous users ** Display custom domain name and logo properly in the top menu (e.g. "digital.auto" + d.a logo, same..."</p>
<hr />
<div>This is an internal page used for Wiki management and maintenance.<br />
<br />
=Important Links=<br />
TBD:<br />
* Documentation<br />
* Create Word PDF from TOC<br />
* Link Wiki page to LinkedIn page/post<br />
* ...<br />
<br />
=Open Tasks=<br />
Wiki backlog, with priorities: short, medium, long term<br />
<br />
==Short Term==<br />
Short term tasks:<br />
* Finalize installation/customization of Minerva<br />
** Use as default for anonymous users<br />
** Display custom domain name and logo properly in the top menu (e.g. "digital.auto" + d.a logo, same for playbook + logo)<br />
** Ensure that for Minerva, the Wiki edit menu options are not visible (takes too long at the moment to hide them)<br />
** Allow for "separator" entries in the left menu (highlighted text, not link)<br />
<br />
==Medium Term==<br />
Medium term tasks:<br />
* TOC: In folded state, texts are displayed in German<br />
* Transfer of digita.auto to DMS, enable HTTPS support<br />
<br />
==Long Term==<br />
Medium term tasks:<br />
* <br />
<br />
== Done ==<br />
List of completed tasks:<br />
* ...</div>Adminhttps://www.digitalplaybook.org/index.php?title=MediaWiki:Common.css&diff=7822MediaWiki:Common.css2023-02-16T16:12:53Z<p>Admin: </p>
<hr />
<div>/* CSS placed here will be applied to all skins */<br />
<br />
/* CSS fixes for digital.auto */<br />
<br />
.floatleft a.image img {<br />
max-width: none !important;<br />
}<br />
<br />
/* TOC css changes */<br />
<br />
#mw-toc-heading::after {<br />
content: " + ";<br />
}<br />
#toctogglecheckbox:checked ~ div #mw-toc-heading::after {<br />
content: " - ";<br />
}</div>Adminhttps://www.digitalplaybook.org/index.php?title=MediaWiki:Common.css&diff=7821MediaWiki:Common.css2023-02-15T16:14:51Z<p>Admin: </p>
<hr />
<div>/* CSS placed here will be applied to all skins */<br />
<br />
/* CSS fixes for digital.auto */<br />
<br />
.floatleft a.image img {<br />
max-width: none !important;<br />
}</div>Adminhttps://www.digitalplaybook.org/index.php?title=MediaWiki:Common.css&diff=7820MediaWiki:Common.css2023-02-15T16:14:35Z<p>Admin: </p>
<hr />
<div>/* CSS placed here will be applied to all skins */<br />
<br />
/* CSS fixes for digital.auto */<br />
<br />
.floatleft a.image img {<br />
max-width: none;<br />
}</div>Adminhttps://www.digitalplaybook.org/index.php?title=MediaWiki:Common.css&diff=7819MediaWiki:Common.css2023-02-15T16:13:37Z<p>Admin: </p>
<hr />
<div>/* CSS placed here will be applied to all skins */<br />
<br />
/* CSS fixes for digital.auto */<br />
<br />
.floatleft a.image img[width:100] {<br />
max-width: none;<br />
}</div>Adminhttps://www.digitalplaybook.org/index.php?title=MediaWiki:Common.css&diff=7818MediaWiki:Common.css2023-02-15T16:12:42Z<p>Admin: Created page with "/* CSS placed here will be applied to all skins */ /* CSS fixes for digital.auto */ .floatleft a.image img[width:100] { max-width: inherit }"</p>
<hr />
<div>/* CSS placed here will be applied to all skins */<br />
<br />
/* CSS fixes for digital.auto */<br />
<br />
.floatleft a.image img[width:100] {<br />
max-width: inherit<br />
}</div>Adminhttps://www.digitalplaybook.org/index.php?title=Digital.autoSidebar&diff=7814Digital.autoSidebar2023-02-07T14:11:18Z<p>Admin: Admin moved page DigitalAutoSidebar to Digital.autoSidebar without leaving a redirect</p>
<hr />
<div>* Overview:_digital.auto|Home<br />
* Overview:_playground.digital.auto|Playground<br />
* Overview:_experience.digital.auto|Experience Simulation<br />
* Overview:_vsm.digital.auto|Value Stream Management<br />
* Overview:_interop.digital.auto|Inter::op<br />
<br />
* Learn:_digital.auto|Overview<br />
* SdV_101|SdV 101<br />
* The_AIoT_Playbook|AIoT Playbook<br />
<br />
* Press|Press<br />
* News|News<br />
* Governance:_digital.auto|Governance</div>Adminhttps://www.digitalplaybook.org/index.php?title=Home:_digital.auto&diff=7813Home: digital.auto2023-02-07T14:08:14Z<p>Admin: </p>
<hr />
<div><imagemap><br />
File:Digital.auto.png|1200px|frameless|center|digital.auto<br />
</imagemap><br />
<br />
<s data-category="digital.auto"></s><br />
<br />
Welcome to the digital.auto project. We aim to help the mobility community deliver on the promise of the "Smart-phone on wheels" vision by combining a strongly use-case driven co-innovation approach with technical enablers such as Software-defined Vehicle, Digital Twin and AIoT.<br />
__TOC__<br />
<br />
=Overview=<br />
The digital.auto project aims to utilize the emerging Software-defined Vehicle infrastructure to bring a truly digital experience to mobility users. For this to happen, on-board and off-board development must be closely aligned. We do this by starting with the identification and prioritization of the most relevant use cases. These are then mapped to off-board apps (mobile, cloud) as well as on-board application services - integrating with the vehicle digital twin to access all relevant vehicle features via true software APIs.<br />
<br />
[[File:Approach.png|800px|frameless|center|Approach]]<br />
<br />
=Workstreams=<br />
The digital.auto currently has 3 main workstreams: playground.digital.auto, simulation.digital.auto and vsm.digital.auto.<br />
playground.digital.auto will provide an in-browser, rapid prototyping environment utilizing the COVESA APIs for connected vehicles. simulation.digital.auto will provide real-world simulation of a connected vehicle, again utilizing the COVESA standards. Finally, vsm.digital.auto provides best practices for automotive project managers and solution architects. A full demo can be accessed on the [[Overview:_playground.digital.auto|VSM workstream page]].<br />
<br />
<imagemap><br />
File:Sub-Projects.png|700px|frameless|center|Workstreams<br />
rect 17 11 968 377 [[Overview:_playground.digital.auto|Playground]]<br />
rect 15 422 965 784 [[Overview:_simulation.digital.auto|Simulation]]<br />
rect 1015 11 1713 784 [[Overview:_vsm.digital.auto|Value Stream Management]]<br />
desc none<br />
</imagemap><br />
<br />
=Summary=<br />
The ultimate goal of digital.auto is to support digital value creation for OEMs in close alignment with the development of the physical elements of the vehicle.<br />
<br />
[[File:Summary.png|800px|frameless|center|Summary]]<br />
<br />
=Event Calendar=<br />
The digital.auto Event Calendar provides an overview of key events where you can meet us and learn more about digital.auto.<br />
<br />
== COVESA All Member Meeting 2022 ==<br />
We will be presenting digital.auto at the [https://www.covesa.global/events COVESA All Member Meeting]. Join us from April 26-28, 2022, in Leipzig, Germany. The Connected Vehicle Systems Alliance (COVESA) defines key standards utilized by digital.auto, such as the Vehicle Signal Specification (VSS) and Vehicle Service Catalogue (VSC).<br />
<br />
== Bosch ConnectedWorld 2022==<br />
<imagemap><br />
File:BCW.png|800px|frameless|center|empty<br />
<br />
desc none<br />
</imagemap><br />
<br />
[https://bosch-connected-world.com/digital-auto/?std1=website_external&std2=ads_external&std3=7012o000001jndT&std4=digitalauto&utm_source=website_external&utm_medium=ads_external&utm_campaign=7012o000001jndT&utm_content=digitalauto|Bosch%20ConnectedWorld Learn More]<br />
<br />
= Authors and Contributors =<br />
{|{{Borderstyle-author}}<br />
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}<br />
<br><br />
{{Designstyle-author|Image=[[File:Nonnenmacher Achim.jpg|left|100px]]|author={{Nonnenmacher Achim|Title=CONTRIBUTOR}}}}<br />
|}</div>Adminhttps://www.digitalplaybook.org/index.php?title=Home:_digital.auto&diff=7811Home: digital.auto2023-02-07T04:14:02Z<p>Admin: </p>
<hr />
<div><imagemap><br />
File:Digital.auto.png|1200px|frameless|center|digital.auto<br />
</imagemap><br />
<br />
<s data-category="DigitalAuto"></s><br />
<br />
Welcome to the digital.auto project. We aim to help the mobility community deliver on the promise of the "Smart-phone on wheels" vision by combining a strongly use-case driven co-innovation approach with technical enablers such as Software-defined Vehicle, Digital Twin and AIoT.<br />
__TOC__<br />
<br />
=Overview=<br />
The digital.auto project aims to utilize the emerging Software-defined Vehicle infrastructure to bring a truly digital experience to mobility users. For this to happen, on-board and off-board development must be closely aligned. We do this by starting with the identification and prioritization of the most relevant use cases. These are then mapped to off-board apps (mobile, cloud) as well as on-board application services - integrating with the vehicle digital twin to access all relevant vehicle features via true software APIs.<br />
<br />
[[File:Approach.png|800px|frameless|center|Approach]]<br />
<br />
=Workstreams=<br />
The digital.auto currently has 3 main workstreams: playground.digital.auto, simulation.digital.auto and vsm.digital.auto.<br />
playground.digital.auto will provide an in-browser, rapid prototyping environment utilizing the COVESA APIs for connected vehicles. simulation.digital.auto will provide real-world simulation of a connected vehicle, again utilizing the COVESA standards. Finally, vsm.digital.auto provides best practices for automotive project managers and solution architects. A full demo can be accessed on the [[Overview:_playground.digital.auto|VSM workstream page]].<br />
<br />
<imagemap><br />
File:Sub-Projects.png|700px|frameless|center|Workstreams<br />
rect 17 11 968 377 [[Overview:_playground.digital.auto|Playground]]<br />
rect 15 422 965 784 [[Overview:_simulation.digital.auto|Simulation]]<br />
rect 1015 11 1713 784 [[Overview:_vsm.digital.auto|Value Stream Management]]<br />
desc none<br />
</imagemap><br />
<br />
=Summary=<br />
The ultimate goal of digital.auto is to support digital value creation for OEMs in close alignment with the development of the physical elements of the vehicle.<br />
<br />
[[File:Summary.png|800px|frameless|center|Summary]]<br />
<br />
=Event Calendar=<br />
The digital.auto Event Calendar provides an overview of key events where you can meet us and learn more about digital.auto.<br />
<br />
== COVESA All Member Meeting 2022 ==<br />
We will be presenting digital.auto at the [https://www.covesa.global/events COVESA All Member Meeting]. Join us from April 26-28, 2022, in Leipzig, Germany. The Connected Vehicle Systems Alliance (COVESA) defines key standards utilized by digital.auto, such as the Vehicle Signal Specification (VSS) and Vehicle Service Catalogue (VSC).<br />
<br />
== Bosch ConnectedWorld 2022==<br />
<imagemap><br />
File:BCW.png|800px|frameless|center|empty<br />
<br />
desc none<br />
</imagemap><br />
<br />
[https://bosch-connected-world.com/digital-auto/?std1=website_external&std2=ads_external&std3=7012o000001jndT&std4=digitalauto&utm_source=website_external&utm_medium=ads_external&utm_campaign=7012o000001jndT&utm_content=digitalauto|Bosch%20ConnectedWorld Learn More]<br />
<br />
= Authors and Contributors =<br />
{|{{Borderstyle-author}}<br />
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}<br />
<br><br />
{{Designstyle-author|Image=[[File:Nonnenmacher Achim.jpg|left|100px]]|author={{Nonnenmacher Achim|Title=CONTRIBUTOR}}}}<br />
|}</div>Adminhttps://www.digitalplaybook.org/index.php?title=Home:_digital.auto&diff=7810Home: digital.auto2023-02-07T04:08:02Z<p>Admin: </p>
<hr />
<div><s data-category="DigitalAuto"></s><br />
<br />
<imagemap><br />
File:Digital.auto.png|1200px|frameless|center|digital.auto<br />
</imagemap><br />
<br />
Welcome to the digital.auto project. We aim to help the mobility community deliver on the promise of the "Smart-phone on wheels" vision by combining a strongly use-case driven co-innovation approach with technical enablers such as Software-defined Vehicle, Digital Twin and AIoT.<br />
__TOC__<br />
<br />
=Overview=<br />
The digital.auto project aims to utilize the emerging Software-defined Vehicle infrastructure to bring a truly digital experience to mobility users. For this to happen, on-board and off-board development must be closely aligned. We do this by starting with the identification and prioritization of the most relevant use cases. These are then mapped to off-board apps (mobile, cloud) as well as on-board application services - integrating with the vehicle digital twin to access all relevant vehicle features via true software APIs.<br />
<br />
[[File:Approach.png|800px|frameless|center|Approach]]<br />
<br />
=Workstreams=<br />
The digital.auto currently has 3 main workstreams: playground.digital.auto, simulation.digital.auto and vsm.digital.auto.<br />
playground.digital.auto will provide an in-browser, rapid prototyping environment utilizing the COVESA APIs for connected vehicles. simulation.digital.auto will provide real-world simulation of a connected vehicle, again utilizing the COVESA standards. Finally, vsm.digital.auto provides best practices for automotive project managers and solution architects. A full demo can be accessed on the [[Overview:_playground.digital.auto|VSM workstream page]].<br />
<br />
<imagemap><br />
File:Sub-Projects.png|700px|frameless|center|Workstreams<br />
rect 17 11 968 377 [[Overview:_playground.digital.auto|Playground]]<br />
rect 15 422 965 784 [[Overview:_simulation.digital.auto|Simulation]]<br />
rect 1015 11 1713 784 [[Overview:_vsm.digital.auto|Value Stream Management]]<br />
desc none<br />
</imagemap><br />
<br />
=Summary=<br />
The ultimate goal of digital.auto is to support digital value creation for OEMs in close alignment with the development of the physical elements of the vehicle.<br />
<br />
[[File:Summary.png|800px|frameless|center|Summary]]<br />
<br />
=Event Calendar=<br />
The digital.auto Event Calendar provides an overview of key events where you can meet us and learn more about digital.auto.<br />
<br />
== COVESA All Member Meeting 2022 ==<br />
We will be presenting digital.auto at the [https://www.covesa.global/events COVESA All Member Meeting]. Join us from April 26-28, 2022, in Leipzig, Germany. The Connected Vehicle Systems Alliance (COVESA) defines key standards utilized by digital.auto, such as the Vehicle Signal Specification (VSS) and Vehicle Service Catalogue (VSC).<br />
<br />
== Bosch ConnectedWorld 2022==<br />
<imagemap><br />
File:BCW.png|800px|frameless|center|empty<br />
<br />
desc none<br />
</imagemap><br />
<br />
[https://bosch-connected-world.com/digital-auto/?std1=website_external&std2=ads_external&std3=7012o000001jndT&std4=digitalauto&utm_source=website_external&utm_medium=ads_external&utm_campaign=7012o000001jndT&utm_content=digitalauto|Bosch%20ConnectedWorld Learn More]<br />
<br />
= Authors and Contributors =<br />
{|{{Borderstyle-author}}<br />
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}<br />
<br><br />
{{Designstyle-author|Image=[[File:Nonnenmacher Achim.jpg|left|100px]]|author={{Nonnenmacher Achim|Title=CONTRIBUTOR}}}}<br />
|}</div>Adminhttps://www.digitalplaybook.org/index.php?title=Digital.autoSidebar&diff=7774Digital.autoSidebar2023-02-05T14:01:55Z<p>Admin: </p>
<hr />
<div>* Overview:_digital.auto|Home<br />
* Overview:_playground.digital.auto|Playground<br />
* Overview:_experience.digital.auto|Experience Simulation<br />
* Overview:_vsm.digital.auto|Value Stream Management<br />
* Overview:_interop.digital.auto|Inter::op<br />
<br />
* Learn:_digital.auto|Overview<br />
* SdV_101|SdV 101<br />
* The_AIoT_Playbook|AIoT Playbook<br />
<br />
* Press|Press<br />
* News|News<br />
* Governance:_digital.auto|Governance</div>Adminhttps://www.digitalplaybook.org/index.php?title=SdV101_Introduction&diff=7756SdV101 Introduction2022-12-19T08:28:34Z<p>Admin: /* Big Picture */</p>
<hr />
<div>__NOTOC__<br />
<imagemap><br />
File:SdV101 Banner Intro.png|2000px|frameless|center|digital.auto<br />
rect 41 120 209 175 [[SdV_101|SdV 101]]<br />
rect 1831 24 1901 70 [[SdV101_Introduction|Introduction]]<br />
rect 1834 79 1903 122 [[SdV101_Value_Stream_Management|Value Stream Management]]<br />
rect 1831 132 1903 178 [[SdV101_Enabling_Technologies|Enablin Technologies]]<br />
rect 1831 187 1903 235 [[SdV101_Digital_First-Exploration|„Digital First“-Exploration]]<br />
rect 1834 240 1903 286 [[SdV101_Enterprise_Architecture_and_Organization|Enterprise Architecture & Organization]]<br />
rect 1836 298 1903 341 [[SdV101_Build,_Measure,_Learn_–_Repeat|Build, Measure, Learn – Repeat]]<br />
desc none<br />
</imagemap><br />
<s data-category="DigitalAuto"></s><br />
After the inital welcome, this introduction provides an overview of the SdV big picture and market drivers, the current situation and inhibitors, the target picture, barriers to Success, and transformation strategies. Finally, an overview of the SdV 101 course will be given.<br />
<br />
__TOC__<br />
<br />
=Welcome=<br />
Watch this brief welcome message by Dirk Slama (Bosch and Steinbeis FSTI) and get an overview of the SdV 101 course: Topics covered by SdV 101, topics NOT covered, plus an outlook how we are planning to extend this SdV learning initiative over time.<br />
<br />
<imagemap><br />
File:SdV101 Welcome.png|600px|frameless|center|empty<br />
rect 1241 910 1356 1059 [https://drive.google.com/file/d/1rpGW87_9r4ObVcUWvttlBXKxgBlNh7c4 Lecture Notes]<br />
circle 196 895 105 [https://youtu.be/Rk3EJ03FlOU PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Big Picture=<br />
The big picture starts by looking at "Smart phone on wheels" as an analogy for the Software-defined Vehicle, including opportunities and challenges such as functional safety. Next, this lesson is discussing the current situation in automotive software development, the idealized target picture, as well as the transformation roadmap to achieve the target picture. All these topics will be covered in more detail in the remainder of this module.<br />
<br />
<imagemap><br />
File:SdV101 BigPicture.png|600px|frameless|center|empty<br />
rect 1241 910 1356 1059 [https://prezi.com/view/yO3KKPKeMutZQ1yLzetJ/ Lecture Notes (Prezi)]<br />
circle 196 895 105 [https://youtu.be/79XL9L1HIn8 PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Market Drivers=<br />
Alex Oyler from SBD Automotive is giving us a short overview of the key market drivers for the Software-defined Vehicle, including value creation, cost reduction, and development speed.<br />
<br />
<imagemap><br />
File:SdV101 SBD MarketDrivers.png|600px|frameless|center|empty<br />
rect 1241 910 1356 1059 [https://drive.google.com/file/d/1MRonPiIQ9ZPBsufLuQcOnkqJxh0coqWJ/view?usp=share_link Lecture Notes (Prezi)]<br />
circle 196 895 105 [https://youtu.be/_hsTt3IxU6w PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Current Situation and Inhibitors=<br />
As we will discuss in the following, many large OEMs are struggling today with very long lead times for new software features, due to he inherent complexity of their hardware, embedded software, and higher-level software architecture. Many cars today have many dozens of highly specialized and often very heterogenous on-board compute units. ECUs (Electronic Control Units) from different vendors and with different hardware, software and networking capabilities are combined in a way which creates a very high level of complexity, leading to today`s high development costs and long time-to-market cycles. The figure below from the article [https://ontonixqcm.blog/2015/09/17/car-electronics-how-much-more-complexity-can-we-handle/ "Car electronics: how much more complexity can we handle?"] is illustrating the point.<br />
<br />
[[File:Complexity.jpg|600px|frameless|center|Complexity]]<br />
<br />
In the following video, Jacek Marczyk, CEO of Ontonix, provides a deep dive on the topic of complexity and how it applies to current vehicle architectures.<br />
<br />
<imagemap><br />
File:SdV101 Complexity.png|600px|frameless|center|empty<br />
circle 196 895 105 [https://youtu.be/djxeb6v8GM0 PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Target Picture=<br />
How does the target picture for Software-defined Vehicle look like? How will this target picture combine the user experience perspective with the value stream perspective? Which role are operational and development value streams are playing in this? And why do we need two main SdV value streams, operating at different speeds? This lesson provides some initial answers.<br />
<br />
<imagemap><br />
File:SdV101 TargetPicture.png|600px|frameless|center|empty<br />
rect 1241 910 1356 1059 [https://drive.google.com/file/d/1b9vTFCSlEu1yrc2-jaEb9LDn4sGULhQ8/view?usp=share_link Lecture Notes]<br />
circle 196 895 105 [https://youtu.be/QjjEBFqndXU PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Transformation Strategies=<br />
This lesson provides a discussion of the different possible target strategies which can be applied by OEMs to achieve the target picture. In the following video, Sebastian Werner, Head of Automotive Software at Kearney & BinaryCore is discussing the options of today`s large OEMs.<br />
<br />
<imagemap><br />
File:SdV101 TransformationStrategy.png|600px|frameless|center|empty<br />
circle 196 895 105 [https://youtu.be/dW-hlZa2QiU PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=SdV 101 Course Overview=<br />
The last lesson of the SdV 101 Introduction provides an overview of the 5 modules following: (01) Value Stream Management, (02) SdV Enabling Technologies, (03) „Digital First“-Exploration, (04) Enterprise Architecture & Organization, and (05) Build, Measure, Learn – Repeat.<br />
<imagemap><br />
File:SdV101 CouseOverview.png|600px|frameless|center|empty<br />
rect 1241 910 1356 1059 [https://drive.google.com/file/d/1QrD_T8o1cDV3HVIUKZaRUntzFWwnfvQD/view?usp=share_link Lecture Notes]<br />
circle 196 895 105 [https://youtu.be/oNtb06kNXhU PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=SdV 101 Framework=<br />
The following figure is showing the SdV 101 Framework, as introduced in the previous lesson. This framework provides the logical structure for all the following modules. Use the framework to navigate to the different modules by clicking on the highlighted areas.<br />
<br />
<imagemap><br />
File:SdV101_Framework.png|800px|frameless|center|SdV101 Framework<br />
<br />
rect 682 557 1831 958 [[SdV101_Value_Stream_Management|01 Value Stream Management]]<br />
rect 106 554 569 965 [[SdV101_Enabling_Technologies|02 Enabling Technologies]]<br />
rect 98 58 1154 298 [[SdV101_Digital_First-Exploration|03 "Digital First"-Exploration]]<br />
rect 682 312 1250 540 [[SdV101_Enterprise_Architecture_and_Organization|04 Enterprise Architecture & Organization]]<br />
rect 1270 53 1829 542 [[SdV101_Build,_Measure,_Learn_–_Repeat|05 Build, measure, learn - repeat]]<br />
<br />
desc none<br />
</imagemap></div>Adminhttps://www.digitalplaybook.org/index.php?title=SdV101_Introduction&diff=7755SdV101 Introduction2022-12-19T08:27:14Z<p>Admin: </p>
<hr />
<div>__NOTOC__<br />
<imagemap><br />
File:SdV101 Banner Intro.png|2000px|frameless|center|digital.auto<br />
rect 41 120 209 175 [[SdV_101|SdV 101]]<br />
rect 1831 24 1901 70 [[SdV101_Introduction|Introduction]]<br />
rect 1834 79 1903 122 [[SdV101_Value_Stream_Management|Value Stream Management]]<br />
rect 1831 132 1903 178 [[SdV101_Enabling_Technologies|Enablin Technologies]]<br />
rect 1831 187 1903 235 [[SdV101_Digital_First-Exploration|„Digital First“-Exploration]]<br />
rect 1834 240 1903 286 [[SdV101_Enterprise_Architecture_and_Organization|Enterprise Architecture & Organization]]<br />
rect 1836 298 1903 341 [[SdV101_Build,_Measure,_Learn_–_Repeat|Build, Measure, Learn – Repeat]]<br />
desc none<br />
</imagemap><br />
<s data-category="DigitalAuto"></s><br />
After the inital welcome, this introduction provides an overview of the SdV big picture and market drivers, the current situation and inhibitors, the target picture, barriers to Success, and transformation strategies. Finally, an overview of the SdV 101 course will be given.<br />
<br />
__TOC__<br />
<br />
=Welcome=<br />
Watch this brief welcome message by Dirk Slama (Bosch and Steinbeis FSTI) and get an overview of the SdV 101 course: Topics covered by SdV 101, topics NOT covered, plus an outlook how we are planning to extend this SdV learning initiative over time.<br />
<br />
<imagemap><br />
File:SdV101 Welcome.png|600px|frameless|center|empty<br />
rect 1241 910 1356 1059 [https://drive.google.com/file/d/1rpGW87_9r4ObVcUWvttlBXKxgBlNh7c4 Lecture Notes]<br />
circle 196 895 105 [https://youtu.be/Rk3EJ03FlOU PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Big Picture=<br />
The big picture starts by looking at "Smart phone on wheels" as an analogy for the Software-defined Vehicle, including opportunities and challenges such as functional safety. Next, this lesson is discussing the current situation in automotive software development, the idealized target picture, as well as the transformation roadmap to achieve the target picture. All these topics will be covered in more detail in the remainder of this module.<br />
<br />
[https://drive.google.com/file/d/1rcorxQuVtU7NYRdiiFVynRxIb2-0jOyi/view?usp=sharing TEST]<br />
<br />
<imagemap><br />
File:SdV101 BigPicture.png|600px|frameless|center|empty<br />
rect 1241 910 1356 1059 [https://prezi.com/view/yO3KKPKeMutZQ1yLzetJ/ Lecture Notes (Prezi)]<br />
circle 196 895 105 [https://youtu.be/79XL9L1HIn8 PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Market Drivers=<br />
Alex Oyler from SBD Automotive is giving us a short overview of the key market drivers for the Software-defined Vehicle, including value creation, cost reduction, and development speed.<br />
<br />
<imagemap><br />
File:SdV101 SBD MarketDrivers.png|600px|frameless|center|empty<br />
rect 1241 910 1356 1059 [https://drive.google.com/file/d/1MRonPiIQ9ZPBsufLuQcOnkqJxh0coqWJ/view?usp=share_link Lecture Notes (Prezi)]<br />
circle 196 895 105 [https://youtu.be/_hsTt3IxU6w PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Current Situation and Inhibitors=<br />
As we will discuss in the following, many large OEMs are struggling today with very long lead times for new software features, due to he inherent complexity of their hardware, embedded software, and higher-level software architecture. Many cars today have many dozens of highly specialized and often very heterogenous on-board compute units. ECUs (Electronic Control Units) from different vendors and with different hardware, software and networking capabilities are combined in a way which creates a very high level of complexity, leading to today`s high development costs and long time-to-market cycles. The figure below from the article [https://ontonixqcm.blog/2015/09/17/car-electronics-how-much-more-complexity-can-we-handle/ "Car electronics: how much more complexity can we handle?"] is illustrating the point.<br />
<br />
[[File:Complexity.jpg|600px|frameless|center|Complexity]]<br />
<br />
In the following video, Jacek Marczyk, CEO of Ontonix, provides a deep dive on the topic of complexity and how it applies to current vehicle architectures.<br />
<br />
<imagemap><br />
File:SdV101 Complexity.png|600px|frameless|center|empty<br />
circle 196 895 105 [https://youtu.be/djxeb6v8GM0 PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Target Picture=<br />
How does the target picture for Software-defined Vehicle look like? How will this target picture combine the user experience perspective with the value stream perspective? Which role are operational and development value streams are playing in this? And why do we need two main SdV value streams, operating at different speeds? This lesson provides some initial answers.<br />
<br />
<imagemap><br />
File:SdV101 TargetPicture.png|600px|frameless|center|empty<br />
rect 1241 910 1356 1059 [https://drive.google.com/file/d/1b9vTFCSlEu1yrc2-jaEb9LDn4sGULhQ8/view?usp=share_link Lecture Notes]<br />
circle 196 895 105 [https://youtu.be/QjjEBFqndXU PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Transformation Strategies=<br />
This lesson provides a discussion of the different possible target strategies which can be applied by OEMs to achieve the target picture. In the following video, Sebastian Werner, Head of Automotive Software at Kearney & BinaryCore is discussing the options of today`s large OEMs.<br />
<br />
<imagemap><br />
File:SdV101 TransformationStrategy.png|600px|frameless|center|empty<br />
circle 196 895 105 [https://youtu.be/dW-hlZa2QiU PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=SdV 101 Course Overview=<br />
The last lesson of the SdV 101 Introduction provides an overview of the 5 modules following: (01) Value Stream Management, (02) SdV Enabling Technologies, (03) „Digital First“-Exploration, (04) Enterprise Architecture & Organization, and (05) Build, Measure, Learn – Repeat.<br />
<imagemap><br />
File:SdV101 CouseOverview.png|600px|frameless|center|empty<br />
rect 1241 910 1356 1059 [https://drive.google.com/file/d/1QrD_T8o1cDV3HVIUKZaRUntzFWwnfvQD/view?usp=share_link Lecture Notes]<br />
circle 196 895 105 [https://youtu.be/oNtb06kNXhU PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=SdV 101 Framework=<br />
The following figure is showing the SdV 101 Framework, as introduced in the previous lesson. This framework provides the logical structure for all the following modules. Use the framework to navigate to the different modules by clicking on the highlighted areas.<br />
<br />
<imagemap><br />
File:SdV101_Framework.png|800px|frameless|center|SdV101 Framework<br />
<br />
rect 682 557 1831 958 [[SdV101_Value_Stream_Management|01 Value Stream Management]]<br />
rect 106 554 569 965 [[SdV101_Enabling_Technologies|02 Enabling Technologies]]<br />
rect 98 58 1154 298 [[SdV101_Digital_First-Exploration|03 "Digital First"-Exploration]]<br />
rect 682 312 1250 540 [[SdV101_Enterprise_Architecture_and_Organization|04 Enterprise Architecture & Organization]]<br />
rect 1270 53 1829 542 [[SdV101_Build,_Measure,_Learn_–_Repeat|05 Build, measure, learn - repeat]]<br />
<br />
desc none<br />
</imagemap></div>Adminhttps://www.digitalplaybook.org/index.php?title=Press&diff=7754Press2022-12-14T13:47:44Z<p>Admin: /* Über digital.auto */</p>
<hr />
<div>__NOTOC__<br />
[[File:Digital.auto.png|2000px|frameless|center|digital.auto]]<br />
<s data-category="DigitalAuto"></s><br />
<br />
=About digital.auto=<br />
digital.auto is an industry-wide initiative enabling the automotive industry to establish a new, digital-first approach for the creation of next-generation customer experiences and data-driven mobility services. Designed as an open ecosystem with a very use-case-centric approach, digital.auto is bringing together automotive original equipment manufacturers (OEMs), suppliers and partners to drive transformation of the industry. The global initiative builds on two key pillars of automotive technology development: the software-defined vehicle (SDV) and standardized vehicle APIs. digital.auto aims to combine existing standards with appropriate methods and best practices to translate technology into business value. Co-initiators include Robert Bosch GmbH as well as software companies Dassault Systèmes and LeanIX. The initiative is hosted by Heilbronn-based Ferdinand-Steinbeis-Institut (FSTI) as a neutral, non-profit facilitator and was launched in November 2022. <br />
<br />
Additional information:<br />
* Home page: http://press.digital.auto<br />
* Media contact: Ines Weybrecht, Communications Manager, info''@''digital.auto<br />
* [https://www.businesswire.com/news/home/20221109005118/en/Start-of-the-Global-digital.auto-Initiative PRESS RELEASE]<br />
<br />
[[File:Digital.auto Overview.jpg|500px|frameless|center|Digital.auto Overview]]<br />
<br />
=Über digital.auto=<br />
digital.auto ist eine industrieweite Initiative. Mit einem Digital First-Ansatz soll der Automobilindustrie ermöglicht werden, die Customer Experience der nächsten Generation sowie datengetriebene Mobilitäts-Services zu entwickeln. Die Initiative ist als offenes Ökosystem konzipiert und nutzt einen auf konkrete Use Cases fokussierten Ansatz. Mit der Zusammenarbeit von Fahrzeugherstellern (OEMs), Zulieferern und Partnern will digital.auto die Transformation der Industrie vorantreiben. Die globale Initiative stützt sich auf zwei wesentliche Säulen in der Entwicklung von Automobiltechnologie: dem Software-definierten Fahrzeug (Software-defined Vehicle/SdV) und standardisierten Fahrzeug-APIs. digital.auto will bestehende Standards mit geeigneten Methoden und Best Practices verbinden, um die Technologie in Geschäftswert zu übersetzen. Zu den Initiatoren zählen die Robert Bosch GmbH und die Software-Unternehmen Dassault Systèmes und LeanIX. Als neutrale Plattform unterstützt das Ferdinand-Steinbeis-Institut (FSTI) aus Heilbronn die im November 2022 gestartete Initiative.<br />
Weitere Details unter http://press.digital.auto<br />
<br />
Weitere Informationen:<br />
* Medienkontakt digital.auto: Ines Weybrecht, Communications Manager, info''@''digital.auto<br />
* [https://www.businesswire.com/news/home/20221109005123/de/ PRESS RELEASE]<br />
<br />
= Media Kit=<br />
The media kit contains:<br />
* Announcement (in [https://drive.google.com/file/d/1twWb56aIdVQHoAvYi1G3XGvZXr5xhOmx/view?usp=share_link English] and [https://drive.google.com/file/d/15JNyOGi9unLHlnepuh4HBBZ7U4d1vGxB/view?usp=sharing German])<br />
* [https://drive.google.com/file/d/1OXmQkMtwO_0ZQwdB-DYPuNvO2lVEhGjO/view?usp=share_link Press kit]<br />
* [https://drive.google.com/file/d/1iF9lcuE1DzBNrKM6ZRb53e7lRMEZsdJ0/view?usp=share_link Overview diagram]<br />
* [https://drive.google.com/file/d/1qgCoQoWGlMLU31WXiuSXzmZ-8to5_UNr/view?usp=share_link Background image]<br />
<br />
=Key Deliverables=<br />
The following provides links to the key deliverables of the digital.auto initiative:<br />
* [[SdV_101|SdV 101 Course]]: The first learning product developed by the digital.auto community is an SdV 101 introductory couser, available as an open access format. It is addressing digital automotive managers, automotive product and project managers, end-to-end solution architects, as well as students.<br />
* [[playground.digital.auto|Playground]]: The digital.auto community is working on an open platform for rapid prototyping and user experience validation. The digital.auto playground is web based on accessible now.<br />
* [https://digitalauto-dev.netlify.app/model/R68RzrffJCkfY5hEBB6N/library/prototype/5WHQKzmIdwup2ldzQ4gP/view/journey Experience Simulation]: Customer Experience is an important use case category for the Software-defined Vehicle. SdV in combination with Experience Simulation help getting early customer feedback and building better experiences.<br />
* [[vsm.digital.auto|Value Stream Management]] (VSM): VSM can be utilized for the alignment of the digital and the physical value streams of the modern OEM. digital.auto is documenting emerging VSM best practices for automotive. A best practice demo has been developed by the community.</div>Adminhttps://www.digitalplaybook.org/index.php?title=Press&diff=7753Press2022-12-14T13:47:29Z<p>Admin: /* About digital.auto */</p>
<hr />
<div>__NOTOC__<br />
[[File:Digital.auto.png|2000px|frameless|center|digital.auto]]<br />
<s data-category="DigitalAuto"></s><br />
<br />
=About digital.auto=<br />
digital.auto is an industry-wide initiative enabling the automotive industry to establish a new, digital-first approach for the creation of next-generation customer experiences and data-driven mobility services. Designed as an open ecosystem with a very use-case-centric approach, digital.auto is bringing together automotive original equipment manufacturers (OEMs), suppliers and partners to drive transformation of the industry. The global initiative builds on two key pillars of automotive technology development: the software-defined vehicle (SDV) and standardized vehicle APIs. digital.auto aims to combine existing standards with appropriate methods and best practices to translate technology into business value. Co-initiators include Robert Bosch GmbH as well as software companies Dassault Systèmes and LeanIX. The initiative is hosted by Heilbronn-based Ferdinand-Steinbeis-Institut (FSTI) as a neutral, non-profit facilitator and was launched in November 2022. <br />
<br />
Additional information:<br />
* Home page: http://press.digital.auto<br />
* Media contact: Ines Weybrecht, Communications Manager, info''@''digital.auto<br />
* [https://www.businesswire.com/news/home/20221109005118/en/Start-of-the-Global-digital.auto-Initiative PRESS RELEASE]<br />
<br />
[[File:Digital.auto Overview.jpg|500px|frameless|center|Digital.auto Overview]]<br />
<br />
=Über digital.auto=<br />
digital.auto ist eine industrieweite Initiative. Mit einem Digital First-Ansatz soll der Automobilindustrie ermöglicht werden, die Customer Experience der nächsten Generation sowie datengetriebene Mobilitäts-Services zu entwickeln. Die Initiative ist als offenes Ökosystem konzipiert und nutzt einen auf konkrete Use Cases fokussierten Ansatz. Mit der Zusammenarbeit von Fahrzeugherstellern (OEMs), Zulieferern und Partnern will digital.auto die Transformation der Industrie vorantreiben. Die globale Initiative stützt sich auf zwei wesentliche Säulen in der Entwicklung von Automobiltechnologie: dem Software-definierten Fahrzeug (Software-defined Vehicle/SdV) und standardisierten Fahrzeug-APIs. digital.auto will bestehende Standards mit geeigneten Methoden und Best Practices verbinden, um die Technologie in Geschäftswert zu übersetzen. Zu den Initiatoren zählen die Robert Bosch GmbH und die Software-Unternehmen Dassault Systèmes und LeanIX. Als neutrale Plattform unterstützt das Ferdinand-Steinbeis-Institut (FSTI) aus Heilbronn die im November 2022 gestartete Initiative.<br />
Weitere Details unter http://press.digital.auto<br />
<br />
Weitere Informationen<br />
* Medienkontakt digital.auto: Ines Weybrecht, Communications Manager, info''@''digital.auto<br />
* [https://www.businesswire.com/news/home/20221109005123/de/ PRESS RELEASE]<br />
<br />
= Media Kit=<br />
The media kit contains:<br />
* Announcement (in [https://drive.google.com/file/d/1twWb56aIdVQHoAvYi1G3XGvZXr5xhOmx/view?usp=share_link English] and [https://drive.google.com/file/d/15JNyOGi9unLHlnepuh4HBBZ7U4d1vGxB/view?usp=sharing German])<br />
* [https://drive.google.com/file/d/1OXmQkMtwO_0ZQwdB-DYPuNvO2lVEhGjO/view?usp=share_link Press kit]<br />
* [https://drive.google.com/file/d/1iF9lcuE1DzBNrKM6ZRb53e7lRMEZsdJ0/view?usp=share_link Overview diagram]<br />
* [https://drive.google.com/file/d/1qgCoQoWGlMLU31WXiuSXzmZ-8to5_UNr/view?usp=share_link Background image]<br />
<br />
=Key Deliverables=<br />
The following provides links to the key deliverables of the digital.auto initiative:<br />
* [[SdV_101|SdV 101 Course]]: The first learning product developed by the digital.auto community is an SdV 101 introductory couser, available as an open access format. It is addressing digital automotive managers, automotive product and project managers, end-to-end solution architects, as well as students.<br />
* [[playground.digital.auto|Playground]]: The digital.auto community is working on an open platform for rapid prototyping and user experience validation. The digital.auto playground is web based on accessible now.<br />
* [https://digitalauto-dev.netlify.app/model/R68RzrffJCkfY5hEBB6N/library/prototype/5WHQKzmIdwup2ldzQ4gP/view/journey Experience Simulation]: Customer Experience is an important use case category for the Software-defined Vehicle. SdV in combination with Experience Simulation help getting early customer feedback and building better experiences.<br />
* [[vsm.digital.auto|Value Stream Management]] (VSM): VSM can be utilized for the alignment of the digital and the physical value streams of the modern OEM. digital.auto is documenting emerging VSM best practices for automotive. A best practice demo has been developed by the community.</div>Adminhttps://www.digitalplaybook.org/index.php?title=Press&diff=7752Press2022-12-14T13:46:51Z<p>Admin: /* About digital.auto */</p>
<hr />
<div>__NOTOC__<br />
[[File:Digital.auto.png|2000px|frameless|center|digital.auto]]<br />
<s data-category="DigitalAuto"></s><br />
<br />
=About digital.auto=<br />
digital.auto is an industry-wide initiative enabling the automotive industry to establish a new, digital-first approach for the creation of next-generation customer experiences and data-driven mobility services. Designed as an open ecosystem with a very use-case-centric approach, digital.auto is bringing together automotive original equipment manufacturers (OEMs), suppliers and partners to drive transformation of the industry. The global initiative builds on two key pillars of automotive technology development: the software-defined vehicle (SDV) and standardized vehicle APIs. digital.auto aims to combine existing standards with appropriate methods and best practices to translate technology into business value. Co-initiators include Robert Bosch GmbH as well as software companies Dassault Systèmes and LeanIX. The initiative is hosted by Heilbronn-based Ferdinand-Steinbeis-Institut (FSTI) as a neutral, non-profit facilitator and was launched in November 2022. <br />
For more details, please visit http://press.digital.auto<br />
<br />
Media contact digital.auto: Ines Weybrecht, Communications Manager, info''@''digital.auto<br />
[https://www.businesswire.com/news/home/20221109005118/en/Start-of-the-Global-digital.auto-Initiative PRESS RELEASE]<br />
<br />
[[File:Digital.auto Overview.jpg|500px|frameless|center|Digital.auto Overview]]<br />
<br />
=Über digital.auto=<br />
digital.auto ist eine industrieweite Initiative. Mit einem Digital First-Ansatz soll der Automobilindustrie ermöglicht werden, die Customer Experience der nächsten Generation sowie datengetriebene Mobilitäts-Services zu entwickeln. Die Initiative ist als offenes Ökosystem konzipiert und nutzt einen auf konkrete Use Cases fokussierten Ansatz. Mit der Zusammenarbeit von Fahrzeugherstellern (OEMs), Zulieferern und Partnern will digital.auto die Transformation der Industrie vorantreiben. Die globale Initiative stützt sich auf zwei wesentliche Säulen in der Entwicklung von Automobiltechnologie: dem Software-definierten Fahrzeug (Software-defined Vehicle/SdV) und standardisierten Fahrzeug-APIs. digital.auto will bestehende Standards mit geeigneten Methoden und Best Practices verbinden, um die Technologie in Geschäftswert zu übersetzen. Zu den Initiatoren zählen die Robert Bosch GmbH und die Software-Unternehmen Dassault Systèmes und LeanIX. Als neutrale Plattform unterstützt das Ferdinand-Steinbeis-Institut (FSTI) aus Heilbronn die im November 2022 gestartete Initiative.<br />
Weitere Details unter http://press.digital.auto<br />
<br />
Weitere Informationen<br />
* Medienkontakt digital.auto: Ines Weybrecht, Communications Manager, info''@''digital.auto<br />
* [https://www.businesswire.com/news/home/20221109005123/de/ PRESS RELEASE]<br />
<br />
= Media Kit=<br />
The media kit contains:<br />
* Announcement (in [https://drive.google.com/file/d/1twWb56aIdVQHoAvYi1G3XGvZXr5xhOmx/view?usp=share_link English] and [https://drive.google.com/file/d/15JNyOGi9unLHlnepuh4HBBZ7U4d1vGxB/view?usp=sharing German])<br />
* [https://drive.google.com/file/d/1OXmQkMtwO_0ZQwdB-DYPuNvO2lVEhGjO/view?usp=share_link Press kit]<br />
* [https://drive.google.com/file/d/1iF9lcuE1DzBNrKM6ZRb53e7lRMEZsdJ0/view?usp=share_link Overview diagram]<br />
* [https://drive.google.com/file/d/1qgCoQoWGlMLU31WXiuSXzmZ-8to5_UNr/view?usp=share_link Background image]<br />
<br />
=Key Deliverables=<br />
The following provides links to the key deliverables of the digital.auto initiative:<br />
* [[SdV_101|SdV 101 Course]]: The first learning product developed by the digital.auto community is an SdV 101 introductory couser, available as an open access format. It is addressing digital automotive managers, automotive product and project managers, end-to-end solution architects, as well as students.<br />
* [[playground.digital.auto|Playground]]: The digital.auto community is working on an open platform for rapid prototyping and user experience validation. The digital.auto playground is web based on accessible now.<br />
* [https://digitalauto-dev.netlify.app/model/R68RzrffJCkfY5hEBB6N/library/prototype/5WHQKzmIdwup2ldzQ4gP/view/journey Experience Simulation]: Customer Experience is an important use case category for the Software-defined Vehicle. SdV in combination with Experience Simulation help getting early customer feedback and building better experiences.<br />
* [[vsm.digital.auto|Value Stream Management]] (VSM): VSM can be utilized for the alignment of the digital and the physical value streams of the modern OEM. digital.auto is documenting emerging VSM best practices for automotive. A best practice demo has been developed by the community.</div>Adminhttps://www.digitalplaybook.org/index.php?title=Press&diff=7751Press2022-12-14T13:45:57Z<p>Admin: /* Über digital.auto */</p>
<hr />
<div>__NOTOC__<br />
[[File:Digital.auto.png|2000px|frameless|center|digital.auto]]<br />
<s data-category="DigitalAuto"></s><br />
<br />
=About digital.auto=<br />
digital.auto is an industry-wide initiative enabling the automotive industry to establish a new, digital-first approach for the creation of next-generation customer experiences and data-driven mobility services. Designed as an open ecosystem with a very use-case-centric approach, digital.auto is bringing together automotive original equipment manufacturers (OEMs), suppliers and partners to drive transformation of the industry. The global initiative builds on two key pillars of automotive technology development: the software-defined vehicle (SDV) and standardized vehicle APIs. digital.auto aims to combine existing standards with appropriate methods and best practices to translate technology into business value. Co-initiators include Robert Bosch GmbH as well as software companies Dassault Systèmes and LeanIX. The initiative is hosted by Heilbronn-based Ferdinand-Steinbeis-Institut (FSTI) as a neutral, non-profit facilitator and was launched in November 2022. <br />
For more details, please visit http://press.digital.auto<br />
<br />
Media contact digital.auto: <br />
Ines Weybrecht, Communications Manager, info''@''digital.auto<br />
<br />
[[File:Digital.auto Overview.jpg|500px|frameless|center|Digital.auto Overview]]<br />
<br />
=Über digital.auto=<br />
digital.auto ist eine industrieweite Initiative. Mit einem Digital First-Ansatz soll der Automobilindustrie ermöglicht werden, die Customer Experience der nächsten Generation sowie datengetriebene Mobilitäts-Services zu entwickeln. Die Initiative ist als offenes Ökosystem konzipiert und nutzt einen auf konkrete Use Cases fokussierten Ansatz. Mit der Zusammenarbeit von Fahrzeugherstellern (OEMs), Zulieferern und Partnern will digital.auto die Transformation der Industrie vorantreiben. Die globale Initiative stützt sich auf zwei wesentliche Säulen in der Entwicklung von Automobiltechnologie: dem Software-definierten Fahrzeug (Software-defined Vehicle/SdV) und standardisierten Fahrzeug-APIs. digital.auto will bestehende Standards mit geeigneten Methoden und Best Practices verbinden, um die Technologie in Geschäftswert zu übersetzen. Zu den Initiatoren zählen die Robert Bosch GmbH und die Software-Unternehmen Dassault Systèmes und LeanIX. Als neutrale Plattform unterstützt das Ferdinand-Steinbeis-Institut (FSTI) aus Heilbronn die im November 2022 gestartete Initiative.<br />
Weitere Details unter http://press.digital.auto<br />
<br />
Weitere Informationen<br />
* Medienkontakt digital.auto: Ines Weybrecht, Communications Manager, info''@''digital.auto<br />
* [https://www.businesswire.com/news/home/20221109005123/de/ PRESS RELEASE]<br />
<br />
= Media Kit=<br />
The media kit contains:<br />
* Announcement (in [https://drive.google.com/file/d/1twWb56aIdVQHoAvYi1G3XGvZXr5xhOmx/view?usp=share_link English] and [https://drive.google.com/file/d/15JNyOGi9unLHlnepuh4HBBZ7U4d1vGxB/view?usp=sharing German])<br />
* [https://drive.google.com/file/d/1OXmQkMtwO_0ZQwdB-DYPuNvO2lVEhGjO/view?usp=share_link Press kit]<br />
* [https://drive.google.com/file/d/1iF9lcuE1DzBNrKM6ZRb53e7lRMEZsdJ0/view?usp=share_link Overview diagram]<br />
* [https://drive.google.com/file/d/1qgCoQoWGlMLU31WXiuSXzmZ-8to5_UNr/view?usp=share_link Background image]<br />
<br />
=Key Deliverables=<br />
The following provides links to the key deliverables of the digital.auto initiative:<br />
* [[SdV_101|SdV 101 Course]]: The first learning product developed by the digital.auto community is an SdV 101 introductory couser, available as an open access format. It is addressing digital automotive managers, automotive product and project managers, end-to-end solution architects, as well as students.<br />
* [[playground.digital.auto|Playground]]: The digital.auto community is working on an open platform for rapid prototyping and user experience validation. The digital.auto playground is web based on accessible now.<br />
* [https://digitalauto-dev.netlify.app/model/R68RzrffJCkfY5hEBB6N/library/prototype/5WHQKzmIdwup2ldzQ4gP/view/journey Experience Simulation]: Customer Experience is an important use case category for the Software-defined Vehicle. SdV in combination with Experience Simulation help getting early customer feedback and building better experiences.<br />
* [[vsm.digital.auto|Value Stream Management]] (VSM): VSM can be utilized for the alignment of the digital and the physical value streams of the modern OEM. digital.auto is documenting emerging VSM best practices for automotive. A best practice demo has been developed by the community.</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7750Playground Backlog2022-11-25T14:29:02Z<p>Admin: /* BCW feedback / new tasks */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car => Louis<br />
* Merge BEG Vehicle + BEG Vehicle 2 => OK<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading => Chris<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop => Chris<br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs => Chris<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck => Devesh<br />
|-<br />
| Passenger Welcome || 1: Images are flickering => Louis; 2: Remove "Passenger Welcome" model => Devesh<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec => Devesh<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec => Devesh<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= Feature Requests=<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Simulation<br />
* Simple simulation: support VSS sensor data import from Google sheet<br />
* Separate project: FleetSim<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins) => Dirk<br />
** Add "Widgets" link to MAIN MENU ("="), pointing to cleaned up version of https://playground-plugins.netlify.app/ => Louis<br />
<br />
UX<br />
* Redundant "play" functions<br />
** Rename tab => "Dashboard" / different icon => Louis<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Code editor: Auto-insert Python code for VSS APIs<br />
** Editing of all text fields (TBD: discuss additional VSS API meta data)<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
User Feedback<br />
* Prototypes<br />
** Enable editing of user feedback, including ratings, comments, effort estimation (1-5)<br />
** Add link to portfolio overview<br />
* Portfolio overview<br />
** In chart, link each circle to corresponding prototype (click on circle opens prototype)<br />
<br />
APIs<br />
* Filter for wishlist APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name<br />
* We need an automated process for creating new accounts<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Longer Term=<br />
* Social Media Integration / LinkedIn</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7749Playground Backlog2022-11-24T08:22:10Z<p>Admin: </p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car => Louis<br />
* Merge BEG Vehicle + BEG Vehicle 2 => OK<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading => Chris<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop => Chris<br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs => Chris<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck => Devesh<br />
|-<br />
| Passenger Welcome || 1: Images are flickering => Louis; 2: Remove "Passenger Welcome" model => Devesh<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec => Devesh<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec => Devesh<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Simulation<br />
* Simple simulation: support VSS sensor data import from Google sheet<br />
* Separate project: FleetSim<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins) => Dirk<br />
** Add "Widgets" link to MAIN MENU ("="), pointing to cleaned up version of https://playground-plugins.netlify.app/ => Louis<br />
<br />
UX<br />
* Redundant "play" functions<br />
** Rename tab => "Dashboard" / different icon => Louis<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Code editor: Auto-insert Python code for VSS APIs<br />
** Editing of all text fields (TBD: discuss additional VSS API meta data)<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
User Feedback<br />
* Prototypes<br />
** Enable editing of user feedback, including ratings, comments, effort estimation (1-5)<br />
** Add link to portfolio overview<br />
* Portfolio overview<br />
** In chart, link each circle to corresponding prototype (click on circle opens prototype)<br />
<br />
APIs<br />
* Filter for wishlist APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name<br />
* We need an automated process for creating new accounts<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Longer Term=<br />
* Social Media Integration / LinkedIn</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7748Playground Backlog2022-11-24T08:16:37Z<p>Admin: </p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car => Louis<br />
* Merge BEG Vehicle + BEG Vehicle 2 => OK<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading => Chris<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop => Chris<br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs => Chris<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck => Devesh<br />
|-<br />
| Passenger Welcome || 1: Images are flickering => Louis; 2: Remove "Passenger Welcome" model => Devesh<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec => Devesh<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec => Devesh<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Simulation<br />
* Simple simulation: support VSS sensor data import from Google sheet<br />
* Separate project: FleetSim<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins) => Dirk<br />
** Add "Widgets" link to MAIN MENU ("="), pointing to cleaned up version of https://playground-plugins.netlify.app/ => Louis<br />
<br />
UX<br />
* Redundant "play" functions<br />
** Rename tab => "Dashboard" / different icon => Louis<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields (TBD: discuss additional VSS API meta data)<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
User Feedback<br />
* Prototypes<br />
** Enable editing of user feedback, including ratings, comments, effort estimation (1-5)<br />
** Add link to portfolio overview<br />
* Portfolio overview<br />
** In chart, link each circle to corresponding prototype (click on circle opens prototype)<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
* Add trace/log of all update: who changed/deleted what when<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Documentation:_playground.digital.auto&diff=7747Documentation: playground.digital.auto2022-11-18T16:43:02Z<p>Admin: /* Overview */</p>
<hr />
<div>[[File:Playground.png|2000px|frameless|center|playground.digital.auto]]<br />
<s data-category="DigitalAuto"></s><br />
<br />
This page provides developer documentation for the digital.auto playground, a web-based, rapid prototyping environment for the Software-defined Vehicle with standardized vehicle APIs. <br />
__TOC__<br />
<br />
=Overview=<br />
<br />
The digital.auto playground provides automotive software developers and product managers with an environment to rapidly develop prototypes for the Software-defined Vehicle (SdV). The environment is purely web-based. Prototypes are developed in Python. To interact with vehicle sensors and actuators, the COVESA [https://wiki.covesa.global/display/WIK4/VSS+-+Vehicle+Signal+Specification Vehicle Signal Specification (VSS)] is used. In the browser environment of the playground, the vehicle sensors and actuators are mocked, using simple test values. Access to VSS in Python is provided via the emerging VSS Python mapping, as defined by the [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas] project (part of [https://sdv.eclipse.org/ Eclipse SdV]). As we will discuss in the following, access to more sophisticated vehicle simulation environments or even real sensors and actuators is possible via a cloud bridge mechanism.<br />
<br />
Also, please check out the following additional resources:<br />
* [https://drive.google.com/file/d/1qYfakx6E592PWBtPzAc_m_LrmBsvaI9K/view?usp=share_link Overview video] of digital.auto playground<br />
* [https://drive.google.com/file/d/1Z-tv5COhmX-lQGtHMSUZWLuvv5PoFAFR/view?usp=share_link Introduction] to digital.auto playground plugin development<br />
* digital.auto playground [https://playground-plugins.netlify.app/ widget documentation]<br />
<br />
=The value of early prototyping=<br />
<br />
The digital.project is promoting a digital-first approach to vehicle development: Develop the vehicle software and applications as early as possible, instead of after the hardware and physical vehicle design. This approach has two main benefits: First, early customer feedback helps to learn which ideas have highest potential for customer value creation. This helps minimizing investments in unpopular features. Fine-tuning the customer journey design early is key for customer acceptance. Of course this does not mean that the software should not constantly be improved later on, even after the Start of Production. After all, this is why DevOps pipelines with OTA for remote vehicle updates are currently being established.<br />
<br />
Second, doing early prototyping also has many benefits from the development perspective: Having a functional mockup early on in the development cycle helps improving transparency between business/IT, across regional and organizational boundaries. If also helps to validate architecture decisions early on, as well as to have a consistent enterprise architecture across all features. Finally, being able to identify API requirements as early as possible is key, because providing an API which encapsulates hardware usually has a very long lead time. This is especially true for hardware and APIs coming from external suppliers.<br />
<br />
[[File:Value of early prototyping.png|800px|frameless|center|Value of early prototyping]]<br />
<br />
=digital.auto value streams=<br />
The following is looking at both, the digital and physical value stream in digital.auto, followed by a discussion of the evolution of code in the digital value stream.<br />
<br />
==Digital and physical value stream==<br />
The digital.auto playground is designed to support the general philosophy of digital.auto, which is assuming two distinct value streams, moving at different speeds: The physical and the digital value stream. These two value streams are de-coupled via a Hardware Abstraction Layer (HAL), which is encapsulating the complexities of vehicle physics, embedded systems, and bus systems. Software components developed in the digital value stream are accessing vehicle functions via well defined interfaces (e.g. VSS). This de-coupling allows components north and south of the API to be (more or less) seamlessly interchanged. For example, a prototype in the playground can first run against simple test values provided by VSS mock implementations in the playground. Next, one might plug in a real vehicle simulation, running south of the API, and providing a more realistic system behavior. Finally, the simulation will be replaced by hardware with real sensors and actuators - starting with a breadboard, and eventually the final vehicle. <br />
<br />
[[File:Value Streams.png|800px|frameless|center|Value Streams]]<br />
<br />
Similarly, north of the API, new SdV features can initially be developed in Python in the playground. Next, the SdV prototype code can be deployed to a professional development environment - as provided, for example, by [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas]. In this environment, the new SdV feature can first be tested in the cloud, before finally being deployed on a vehicle computer.<br />
<br />
==Code evolution in the digital value stream==<br />
<br />
In order for the SdV code not to break when moving from the playground to the real development environment, the VSS Python APIs are currently being standardized by the Eclipse community. This allows to migrate code more easily between different environments. For example, as described in the figure below, an SdV function might initially be implemented as a prototype in the digital.auto playground. After the initial customer validation, the decision is made to migrate the code from the prototyping environment to the professional development environment, including proper support for CI/CD. This can be done easily because of the standardization of the Python APIs. In fact, the next release of the playground will have built-in support to deploy into Eclipse Velocitas by creating a complete Velocitas project in GitHub, based on the initial prototype.<br />
<br />
[[File:Deployment and code evolution.png|450px|frameless|center|Deployment and code evolution]]<br />
<br />
One important note: Even if the final target language for the production system is not Python - but maybe C++ or Rust - having a Python prototype for early vehicle tests is extremely valuable, because it helps getting an end-to-end implementation done quickly, and stabilizing the APIs between the distributed components.<br />
<br />
= VSS Python API =<br />
<br />
The VSS API is organized in a strict tree hierarchy. The nodes of the VSS tree are called branches. The leaves in the tree are representing sensors, actuators, and attributes. An example for a sensor representation in VSS looks like this:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.IsBelted</code><br />
<br />
This VSS API or data point will return a boolean value, indicating whether the belt is engaged. Please note that the VSS API catalogue can be adapted for individual vehicle instances - for example, supporting vehicles with different numbers of seat rows.<br />
<br />
An example for an actuator in VSS is shown in the following:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline</code><br />
<br />
This API will control the seat z-axis depends on seat tilt.<br />
<br />
==get()/set() functions==<br />
<br />
Using the VSS API in Python is straight forward. For example, to get the current state of a seat belt, the following code can be used:<br />
<br />
<code><br />
from ACME_Car_EV_v01 import Vehicle<br><br />
vehicle = Vehicle()<br><br />
vehicle.Cabin.Seat.Row1.Pos1.IsBelted.get()<br><br />
</code><br />
<br />
The <code>get()</code> function will simply return the current state of the <code>IsBelted</code> sensor represented by the corresponding Python object in the digital.auto playground library.<br />
<br />
Not very surprisingly, to control an actuator, a <code>set()</code> API is provided in Pyhton, e.g.:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.set(25)<br />
</code><br />
<br />
However, as straight-forward as this code actually looks like, the logic behind it is not as straight forward - the reason being that this API is supposed to control a physical device, which might not react immediately to the request (or maybe not at all). From the [https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/sensor_actuator/ VSS specification]: ''“Actuators are used to control the desired value of a property. Some properties in a vehicle cannot change instantly. A typical example is position of a seat or a window. Reading a value of an actuator shall return the current actual value, e.g. the current position of the seat, rather than the wanted/desired position. A typical example could be if someone wants to change the position of a seat from 0 to 100. This can be changed by setting the corresponding actuator to 100. If the actuator is read directly after the set request it will still return 0 as it might take some seconds before the seat reaches the wanted position of 100. If the seat by some reason is blocked or cannot be moved due to safety reasons it might never reach the wanted position. It is up to the vehicle to decide how long time it shall try to reach the desired value and what to do if it needs to give up.”'' <br />
<br />
Even though <code>BackrestRecline</code> is encapsulating an actuator, its current value can be read using <code>get()</code>:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.get()<br />
</code><br />
<br />
However, as per the above discussing please note that it might not be 100% clear what the return value is actually indicating. Note that there is work going on at the moment to support APIs which differentiate between the actual value vs the intended value of an actuator.<br />
<br />
Finally, please also note that the current version of VSS used here is not supporting meta data in the API that could be used to support additional service level, including real-time requirements, request priorization, etc. This means that the SdV code using VSS currently is aiming at applications which are labeled as "QM", according to the [https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level ASIL] standard - meaning the code does not support any of the higher ASIL safety levels, such as ASIL A, B, C or D.<br />
<br />
== Event listeners ==<br />
When dealing with sensor data - even for mocked sensors - it can often make sense to use a more event-driven model, instead of constantly polling the sensor. To support this, the Python API for VSS is supporting a simple event-driven programming model. Using the <code>subscribe()</code> method, a callback function can be associated with a sensor. This function will be called every time a new value is available.<br />
<br />
In the following code sample, a new function <code>on_hood_is_open_changed</code> is defined, and then associated with <code>vehicle.Body.Hood.IsOpen</code> via the <code>subscribe()</code> method. After this, a mock wiper is turned on to MEDIUM speed. Next, the mock hood is opened. This will result in <code>on_hood_is_open_changed</code> being called, which in turn will turn the wipers off.<br />
<br />
<code><br />
def on_hood_is_open_changed(IsOpen: bool):<br />
if IsOpen:<br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.OFF)<br />
vehicle.Body.Hood.IsOpen.subscribe(on_hood_is_open_changed)<br><br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.MEDIUM)<br><br />
vehicle.Body.Hood.IsOpen.set(True)<br><br />
</code><br />
<br />
=Playground architecture=<br />
The following provides an overview of the playground architecture, as well as the key elements of the plugin concept.<br />
<br />
==Overview==<br />
The digital.auto playground is designed to allow execution of SdV Python code against the standard VSS Python API. The SdV Python code is executed in the browser, against a set of Python objects representing the VSS API. To ensure a good user experience, the playground also has to support easy manipulation of the HTML Document Object Model (DOM), as well as remote interaction with the cloud. Since most browser development is done in JavaScript these days, the playground supports a plug-in mechanism which is implemented in JavaScript. This means that the SdV Prototypes in Pyhton are really interacting with VSS objects which are implemented in JavaScript. This way, a vehicle mockup can easily be built using browser-native tools. The mechanism used here is a Python-to-JavaScript bridge, which is translating between the SdV functions in Python and the plug-ins in JavaScript. <br />
<br />
[[File:Playground Architecture.png|800px|frameless|center|Playground Architecture]]<br />
<br />
==Playground plugins==<br />
<br />
Plugins for the digital.auto playground are usually providing a mockup and a visualization of a specific vehicle feature, exposed via VSS. An example could be a Google maps plugin, which is visualizing the vehicle's current position by accessing <code>Vehicle.CurrentLocation</code>.<br />
<br />
A plugin can provide two things:<br />
* Widget which are providing the UX to visualize the behavior represented by one or more VSS APIs<br />
* Simulators which are implementing VSS APIs<br />
<br />
An SdV prototype that wants to make use of a plugin must do two things:<br />
* Import the plugin Python library<br />
* Configure the plugins used (especially the UX layout)<br />
<br />
Plugins can be combined in different ways. For example, an SdV prototype might import the Google maps plugin to visualize the vehicle`s position on a map, plus another plugin which is actually implementing <code>Vehicle.CurrentLocation</code>. Or, the UX and the VSS implementation might be combined in one plugin, depending on the design.<br />
<br />
[[File:Plugin Overview.png|800px|frameless|center|Plugin Overview]]<br />
<br />
The digital.auto project is aiming to build up a rich plug-in library over time.<br />
However, often it will be required to implement dedicated plugins for a specific prototype.<br />
To support this, the plugin mechanism in the playground is open, both for plugin consumption as well as provisioning.<br />
<br />
For the implementer of a plugin, the following provides more detailed instructions for doing so.<br />
<br />
==Simulators==<br />
By default, the VSS Python API is providing an implementation which provides a very basic functionality: the <code>get()</code> functions are returning the current value (initialized randomly). The <code>set()</code> functions are storing the value passed to them.<br />
<br />
Simulators are providing a way to change this functionality. They allow plug-in developers to implement more specific functions for a given VSS sensors, actuator, or attribute. For example, a get function could communicate with a remote service in the cloud to receive the current sensor value. This can be any cloud, assuming that Cross-Origin Resource Sharing (CORS) or an alternative mechanism is used.<br />
<br />
A simulator can also be combined with a widget, e.g. to visualize a new sensor value.<br />
<br />
==Widgets==<br />
Widgets can use the built-in grid area of the playground to visualize vehicle functions, or even provide an interactive experience - using standard browser functionality. The grid is divided into 5x2 grid cells. A widget can occupy 1 or more grid cells, always assuming a rectangular shape.<br />
<br />
The grid mechanism is designed as simple as possible (we wanted to avoid the complexities of a full-blown portal server), yet giving a lot of flexibility. Each widget is mapped to an iFrame, meaning that a widget can use all functionalities which an iFrame supports.<br />
<br />
When designing a widget, using the right size must be ensured. For example, the ideal size for a 2x1 box video in the grid would be: 1080x756<br />
<br />
It doesn't need to be exact, but<br />
* Any size smaller would need to be centered, with space on all sides.<br />
* Any size larger would appear the exact same, but would take more time to load.<br />
* Any change in ratio would mean extra space (either horizontally or vertically)<br />
<br />
==Default Widget Style==<br />
Ideally, different widgets should use a similar style, so that if multiple widgets from different source are combined, they provide a consistent use experience. To achieve this, digital.auto recommends the following:<br />
* Use the following font: https://www.w3schools.com/cssref/css_websafe_fonts.php<br />
* Use only the colors defined on the following table, plus black/white<br />
<br />
[[File:Digital.auto colors.png|800px|frameless|center|digital.auto colors]]<br />
<br />
= Using plugins=<br />
In order to use a plugin, it needs to be imported and configured. The configuration is necessary so that the playground understands which prototypes should be used, and how to map them to the playground`s grid-based widget layout. The following example is configuring the use of two plugins, InstrumentPanel and SmartPhone:<br />
<br />
<code><br />
[<br><br />
{<br><br />
"boxes": [2, 3],<br><br />
"plugin": "InstrumentPanel",<br><br />
"widget": "Speedometer"<br><br />
},<br><br />
{<br><br />
"boxes": [1],<br><br />
"plugin": "SmartPhone",<br><br />
"widget": "Image"<br><br />
}<br><br />
]<br></code><br />
<br />
In this example, SmartPhone will occupy the first position in the playground grid, the Instrument panel the 2nd and 3rd.<br />
<br />
In order now to use these plugins in Python, the SdV prototype has to import <code>plugins</code>, like in the following example:<br />
<br />
<code><br />
from ACME_Car_ICE_v01 import Vehicle<br><br />
import plugins<br><br />
<br />
plugins.SmartPhone.set_text("Added text to SmartPhone")<br><br />
<br />
vehicle = Vehicle()<br><br />
<br />
await vehicle.Cabin.InstrumentPanel.Status.set(f"TEXT IN InstrumentPanel")<br><br />
<br />
</code><br />
<br />
In this example, a text is added via a proprietary API to a the mockup of a Smart Phone. This is because a Smart Phone is not part of VSS.<br />
Next, a text is added to <code>Vehicle.Cabin.InstrumentPanel.Status</code>. In this case, <code>InstrumentPanel.Status</code> was added to the VSS API as a Wishlist-Item, because this could actually make sense from a VSS perspective.<br />
<br />
= Implementing plugins=<br />
A plugin is made up of a Python module with one default exported function, that takes two deconstructed object parameters: <code>widgets</code> and <code>simulator</code>. Both are described in the following:<br />
<br />
==Widgets==<br />
<code>widgets</code> has one method, <code>register</code> that allows you to register widgets that can used by all the prototypes in the model through the '''Widgets Config''':<br />
<br />
<code><br />
register(widget_name: string, onActivate: (container: Container) => undefined | WidgetDeactivateFunction) => undefined<br />
</code><br />
<br />
===Container===<br />
Container has 3 properties:<br />
<br />
{| class="wikitable"<br />
|-<br />
! # !! Argument !! Description<br />
|-<br />
| 1 || <code>injectHTML(html: string) => void</code>|| <code>injectHTML</code> is used to inject html in the box, essentially setting its <code>innerHTML</code>.<br />
|-<br />
| 2 || <code>injectNode(node: Node) => void</code> || <code>injectNode</code> is used to inject an HTML Node (element or fragment) in the box. This is usually needed for complex use cases that <code>injectHTML</code> can't be used for, like event listeners.<br />
|-<br />
| 3 || window || The window object of the container iframe.<br />
|}<br />
<br />
===WidgetDeactivateFunction() => void===<br />
The deactivate function is executed whenever a widget is removed from the grid. This is useful for clearing stuff such as<br />
intervals<br />
<br />
==Simulator==<br />
<code><br />
simulator(api: string, method: "get" | "set" | "subscribe", func: SimulatorModifier) => void<br />
</code><br />
<br />
<code>simulator</code> is a function that let's you override any VSS API's get , set and subscribe methods<br />
<br />
It accepts 3 parameters:<br />
# <code>api</code>: The name of the VSS API to override, for example: Vehicle.Body.Hood.IsOpen<br />
# <code>method</code>: The method to override, this can be only one of get, set, or subscribe.<br />
# <code>func</code>: The modifier that is run when the API method is called, of SimulatorModifier type<br />
<br />
<code>SimulatorModifer</code> is called with two deconstructed object parameters:<br />
# <code>args: any[]</code>: Array of arguments passed in the Python code to the method, converted to equivalent JS types.<br />
# <code>prevReturnValue: any</code>: The return value this method would return if the prevReturnValue is undefined.<br />
Multiple plugins can each attach multiple modifiers to a method, all these modifiers will be called in the same order they were<br />
attached.<br />
<br />
The return value of the previous modifier will be passed to <code>prevReturnValue</code>.<br />
<br />
==Widgets Config==<br />
The widgets config is a JSON array of <code>GridItem</code> objects specified in the code tab of the prototype.<br />
<br />
GridItem has 3 properties:<br />
# <code>boxes: number[]</code>: The boxes this grid item should occupy. Boxes must be adjacent (horizontally or vertically) and for<br />
now, a grid item can occupy a maximum of 2 boxes.<br />
# <code>plugin: string</code>: The name of the plugin for this widget. This is the plugin name specified when creating a plugin.<br />
# <code>widget: string</code>: The widget name. This is specified in the plugin code when registering a widget<br />
<br />
= Summary =<br />
The following provides an overview of all elements involved: A vehicle model in the playground includes one instance of a VSS catalogue (e.g. the YAML definition file with all the VSS definitions), n number of plugin implementations, and n number of SdV prototypes. <br />
<br />
The VSS catalogue can be extended to use VSS Wishlist items, defined ad-hoc by different prototypes. digital.auto and COVESA are currently working on a way to submit items from the VSS Wishlist to the COVESA process for standardization of VSS.<br />
<br />
Plugins are defining simulators and widgets. Widgets are providing the UX for simulators (defined in the same of other plugins). In the future, each plugin will be associated with one SdV prototype for documentation purposes, as well as for defining the VSS wishlist APIs which might be required by the plugin.<br />
<br />
SdV prototypes are using plugins. In order to use a plugin, the configuration will have to state where exactly the required widgets should be played on the prototype-specific version of the playground grid.<br />
<br />
[[File:All Playground Elements.png|800px|frameless|center|All Playground Elements]]</div>Adminhttps://www.digitalplaybook.org/index.php?title=Documentation:_playground.digital.auto&diff=7746Documentation: playground.digital.auto2022-11-18T16:42:44Z<p>Admin: </p>
<hr />
<div>[[File:Playground.png|2000px|frameless|center|playground.digital.auto]]<br />
<s data-category="DigitalAuto"></s><br />
<br />
This page provides developer documentation for the digital.auto playground, a web-based, rapid prototyping environment for the Software-defined Vehicle with standardized vehicle APIs. <br />
__TOC__<br />
<br />
=Overview=<br />
<br />
The digital.auto playground provides automotive software developers and product managers with an environment to rapidly develop prototypes for the Software-defined Vehicle (SdV). The environment is purely web-based. Prototypes are developed in Python. To interact with vehicle sensors and actuators, the COVESA [https://wiki.covesa.global/display/WIK4/VSS+-+Vehicle+Signal+Specification Vehicle Signal Specification (VSS)] is used. In the browser environment of the playground, the vehicle sensors and actuators are mocked, using simple test values. Access to VSS in Python is provided via the emerging VSS Python mapping, as defined by the [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas] project (part of [https://sdv.eclipse.org/ Eclipse SdV]). As we will discuss in the following, access to more sophisticated vehicle simulation environments or even real sensors and actuators is possible via a cloud bridge mechanism.<br />
<br />
Also check out the following additional resources:<br />
* [https://drive.google.com/file/d/1qYfakx6E592PWBtPzAc_m_LrmBsvaI9K/view?usp=share_link Overview video] of digital.auto playground<br />
* [https://drive.google.com/file/d/1Z-tv5COhmX-lQGtHMSUZWLuvv5PoFAFR/view?usp=share_link Introduction] to digital.auto playground plugin development<br />
* digital.auto playground [https://playground-plugins.netlify.app/ widget documentation]<br />
<br />
=The value of early prototyping=<br />
<br />
The digital.project is promoting a digital-first approach to vehicle development: Develop the vehicle software and applications as early as possible, instead of after the hardware and physical vehicle design. This approach has two main benefits: First, early customer feedback helps to learn which ideas have highest potential for customer value creation. This helps minimizing investments in unpopular features. Fine-tuning the customer journey design early is key for customer acceptance. Of course this does not mean that the software should not constantly be improved later on, even after the Start of Production. After all, this is why DevOps pipelines with OTA for remote vehicle updates are currently being established.<br />
<br />
Second, doing early prototyping also has many benefits from the development perspective: Having a functional mockup early on in the development cycle helps improving transparency between business/IT, across regional and organizational boundaries. If also helps to validate architecture decisions early on, as well as to have a consistent enterprise architecture across all features. Finally, being able to identify API requirements as early as possible is key, because providing an API which encapsulates hardware usually has a very long lead time. This is especially true for hardware and APIs coming from external suppliers.<br />
<br />
[[File:Value of early prototyping.png|800px|frameless|center|Value of early prototyping]]<br />
<br />
=digital.auto value streams=<br />
The following is looking at both, the digital and physical value stream in digital.auto, followed by a discussion of the evolution of code in the digital value stream.<br />
<br />
==Digital and physical value stream==<br />
The digital.auto playground is designed to support the general philosophy of digital.auto, which is assuming two distinct value streams, moving at different speeds: The physical and the digital value stream. These two value streams are de-coupled via a Hardware Abstraction Layer (HAL), which is encapsulating the complexities of vehicle physics, embedded systems, and bus systems. Software components developed in the digital value stream are accessing vehicle functions via well defined interfaces (e.g. VSS). This de-coupling allows components north and south of the API to be (more or less) seamlessly interchanged. For example, a prototype in the playground can first run against simple test values provided by VSS mock implementations in the playground. Next, one might plug in a real vehicle simulation, running south of the API, and providing a more realistic system behavior. Finally, the simulation will be replaced by hardware with real sensors and actuators - starting with a breadboard, and eventually the final vehicle. <br />
<br />
[[File:Value Streams.png|800px|frameless|center|Value Streams]]<br />
<br />
Similarly, north of the API, new SdV features can initially be developed in Python in the playground. Next, the SdV prototype code can be deployed to a professional development environment - as provided, for example, by [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas]. In this environment, the new SdV feature can first be tested in the cloud, before finally being deployed on a vehicle computer.<br />
<br />
==Code evolution in the digital value stream==<br />
<br />
In order for the SdV code not to break when moving from the playground to the real development environment, the VSS Python APIs are currently being standardized by the Eclipse community. This allows to migrate code more easily between different environments. For example, as described in the figure below, an SdV function might initially be implemented as a prototype in the digital.auto playground. After the initial customer validation, the decision is made to migrate the code from the prototyping environment to the professional development environment, including proper support for CI/CD. This can be done easily because of the standardization of the Python APIs. In fact, the next release of the playground will have built-in support to deploy into Eclipse Velocitas by creating a complete Velocitas project in GitHub, based on the initial prototype.<br />
<br />
[[File:Deployment and code evolution.png|450px|frameless|center|Deployment and code evolution]]<br />
<br />
One important note: Even if the final target language for the production system is not Python - but maybe C++ or Rust - having a Python prototype for early vehicle tests is extremely valuable, because it helps getting an end-to-end implementation done quickly, and stabilizing the APIs between the distributed components.<br />
<br />
= VSS Python API =<br />
<br />
The VSS API is organized in a strict tree hierarchy. The nodes of the VSS tree are called branches. The leaves in the tree are representing sensors, actuators, and attributes. An example for a sensor representation in VSS looks like this:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.IsBelted</code><br />
<br />
This VSS API or data point will return a boolean value, indicating whether the belt is engaged. Please note that the VSS API catalogue can be adapted for individual vehicle instances - for example, supporting vehicles with different numbers of seat rows.<br />
<br />
An example for an actuator in VSS is shown in the following:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline</code><br />
<br />
This API will control the seat z-axis depends on seat tilt.<br />
<br />
==get()/set() functions==<br />
<br />
Using the VSS API in Python is straight forward. For example, to get the current state of a seat belt, the following code can be used:<br />
<br />
<code><br />
from ACME_Car_EV_v01 import Vehicle<br><br />
vehicle = Vehicle()<br><br />
vehicle.Cabin.Seat.Row1.Pos1.IsBelted.get()<br><br />
</code><br />
<br />
The <code>get()</code> function will simply return the current state of the <code>IsBelted</code> sensor represented by the corresponding Python object in the digital.auto playground library.<br />
<br />
Not very surprisingly, to control an actuator, a <code>set()</code> API is provided in Pyhton, e.g.:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.set(25)<br />
</code><br />
<br />
However, as straight-forward as this code actually looks like, the logic behind it is not as straight forward - the reason being that this API is supposed to control a physical device, which might not react immediately to the request (or maybe not at all). From the [https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/sensor_actuator/ VSS specification]: ''“Actuators are used to control the desired value of a property. Some properties in a vehicle cannot change instantly. A typical example is position of a seat or a window. Reading a value of an actuator shall return the current actual value, e.g. the current position of the seat, rather than the wanted/desired position. A typical example could be if someone wants to change the position of a seat from 0 to 100. This can be changed by setting the corresponding actuator to 100. If the actuator is read directly after the set request it will still return 0 as it might take some seconds before the seat reaches the wanted position of 100. If the seat by some reason is blocked or cannot be moved due to safety reasons it might never reach the wanted position. It is up to the vehicle to decide how long time it shall try to reach the desired value and what to do if it needs to give up.”'' <br />
<br />
Even though <code>BackrestRecline</code> is encapsulating an actuator, its current value can be read using <code>get()</code>:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.get()<br />
</code><br />
<br />
However, as per the above discussing please note that it might not be 100% clear what the return value is actually indicating. Note that there is work going on at the moment to support APIs which differentiate between the actual value vs the intended value of an actuator.<br />
<br />
Finally, please also note that the current version of VSS used here is not supporting meta data in the API that could be used to support additional service level, including real-time requirements, request priorization, etc. This means that the SdV code using VSS currently is aiming at applications which are labeled as "QM", according to the [https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level ASIL] standard - meaning the code does not support any of the higher ASIL safety levels, such as ASIL A, B, C or D.<br />
<br />
== Event listeners ==<br />
When dealing with sensor data - even for mocked sensors - it can often make sense to use a more event-driven model, instead of constantly polling the sensor. To support this, the Python API for VSS is supporting a simple event-driven programming model. Using the <code>subscribe()</code> method, a callback function can be associated with a sensor. This function will be called every time a new value is available.<br />
<br />
In the following code sample, a new function <code>on_hood_is_open_changed</code> is defined, and then associated with <code>vehicle.Body.Hood.IsOpen</code> via the <code>subscribe()</code> method. After this, a mock wiper is turned on to MEDIUM speed. Next, the mock hood is opened. This will result in <code>on_hood_is_open_changed</code> being called, which in turn will turn the wipers off.<br />
<br />
<code><br />
def on_hood_is_open_changed(IsOpen: bool):<br />
if IsOpen:<br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.OFF)<br />
vehicle.Body.Hood.IsOpen.subscribe(on_hood_is_open_changed)<br><br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.MEDIUM)<br><br />
vehicle.Body.Hood.IsOpen.set(True)<br><br />
</code><br />
<br />
=Playground architecture=<br />
The following provides an overview of the playground architecture, as well as the key elements of the plugin concept.<br />
<br />
==Overview==<br />
The digital.auto playground is designed to allow execution of SdV Python code against the standard VSS Python API. The SdV Python code is executed in the browser, against a set of Python objects representing the VSS API. To ensure a good user experience, the playground also has to support easy manipulation of the HTML Document Object Model (DOM), as well as remote interaction with the cloud. Since most browser development is done in JavaScript these days, the playground supports a plug-in mechanism which is implemented in JavaScript. This means that the SdV Prototypes in Pyhton are really interacting with VSS objects which are implemented in JavaScript. This way, a vehicle mockup can easily be built using browser-native tools. The mechanism used here is a Python-to-JavaScript bridge, which is translating between the SdV functions in Python and the plug-ins in JavaScript. <br />
<br />
[[File:Playground Architecture.png|800px|frameless|center|Playground Architecture]]<br />
<br />
==Playground plugins==<br />
<br />
Plugins for the digital.auto playground are usually providing a mockup and a visualization of a specific vehicle feature, exposed via VSS. An example could be a Google maps plugin, which is visualizing the vehicle's current position by accessing <code>Vehicle.CurrentLocation</code>.<br />
<br />
A plugin can provide two things:<br />
* Widget which are providing the UX to visualize the behavior represented by one or more VSS APIs<br />
* Simulators which are implementing VSS APIs<br />
<br />
An SdV prototype that wants to make use of a plugin must do two things:<br />
* Import the plugin Python library<br />
* Configure the plugins used (especially the UX layout)<br />
<br />
Plugins can be combined in different ways. For example, an SdV prototype might import the Google maps plugin to visualize the vehicle`s position on a map, plus another plugin which is actually implementing <code>Vehicle.CurrentLocation</code>. Or, the UX and the VSS implementation might be combined in one plugin, depending on the design.<br />
<br />
[[File:Plugin Overview.png|800px|frameless|center|Plugin Overview]]<br />
<br />
The digital.auto project is aiming to build up a rich plug-in library over time.<br />
However, often it will be required to implement dedicated plugins for a specific prototype.<br />
To support this, the plugin mechanism in the playground is open, both for plugin consumption as well as provisioning.<br />
<br />
For the implementer of a plugin, the following provides more detailed instructions for doing so.<br />
<br />
==Simulators==<br />
By default, the VSS Python API is providing an implementation which provides a very basic functionality: the <code>get()</code> functions are returning the current value (initialized randomly). The <code>set()</code> functions are storing the value passed to them.<br />
<br />
Simulators are providing a way to change this functionality. They allow plug-in developers to implement more specific functions for a given VSS sensors, actuator, or attribute. For example, a get function could communicate with a remote service in the cloud to receive the current sensor value. This can be any cloud, assuming that Cross-Origin Resource Sharing (CORS) or an alternative mechanism is used.<br />
<br />
A simulator can also be combined with a widget, e.g. to visualize a new sensor value.<br />
<br />
==Widgets==<br />
Widgets can use the built-in grid area of the playground to visualize vehicle functions, or even provide an interactive experience - using standard browser functionality. The grid is divided into 5x2 grid cells. A widget can occupy 1 or more grid cells, always assuming a rectangular shape.<br />
<br />
The grid mechanism is designed as simple as possible (we wanted to avoid the complexities of a full-blown portal server), yet giving a lot of flexibility. Each widget is mapped to an iFrame, meaning that a widget can use all functionalities which an iFrame supports.<br />
<br />
When designing a widget, using the right size must be ensured. For example, the ideal size for a 2x1 box video in the grid would be: 1080x756<br />
<br />
It doesn't need to be exact, but<br />
* Any size smaller would need to be centered, with space on all sides.<br />
* Any size larger would appear the exact same, but would take more time to load.<br />
* Any change in ratio would mean extra space (either horizontally or vertically)<br />
<br />
==Default Widget Style==<br />
Ideally, different widgets should use a similar style, so that if multiple widgets from different source are combined, they provide a consistent use experience. To achieve this, digital.auto recommends the following:<br />
* Use the following font: https://www.w3schools.com/cssref/css_websafe_fonts.php<br />
* Use only the colors defined on the following table, plus black/white<br />
<br />
[[File:Digital.auto colors.png|800px|frameless|center|digital.auto colors]]<br />
<br />
= Using plugins=<br />
In order to use a plugin, it needs to be imported and configured. The configuration is necessary so that the playground understands which prototypes should be used, and how to map them to the playground`s grid-based widget layout. The following example is configuring the use of two plugins, InstrumentPanel and SmartPhone:<br />
<br />
<code><br />
[<br><br />
{<br><br />
"boxes": [2, 3],<br><br />
"plugin": "InstrumentPanel",<br><br />
"widget": "Speedometer"<br><br />
},<br><br />
{<br><br />
"boxes": [1],<br><br />
"plugin": "SmartPhone",<br><br />
"widget": "Image"<br><br />
}<br><br />
]<br></code><br />
<br />
In this example, SmartPhone will occupy the first position in the playground grid, the Instrument panel the 2nd and 3rd.<br />
<br />
In order now to use these plugins in Python, the SdV prototype has to import <code>plugins</code>, like in the following example:<br />
<br />
<code><br />
from ACME_Car_ICE_v01 import Vehicle<br><br />
import plugins<br><br />
<br />
plugins.SmartPhone.set_text("Added text to SmartPhone")<br><br />
<br />
vehicle = Vehicle()<br><br />
<br />
await vehicle.Cabin.InstrumentPanel.Status.set(f"TEXT IN InstrumentPanel")<br><br />
<br />
</code><br />
<br />
In this example, a text is added via a proprietary API to a the mockup of a Smart Phone. This is because a Smart Phone is not part of VSS.<br />
Next, a text is added to <code>Vehicle.Cabin.InstrumentPanel.Status</code>. In this case, <code>InstrumentPanel.Status</code> was added to the VSS API as a Wishlist-Item, because this could actually make sense from a VSS perspective.<br />
<br />
= Implementing plugins=<br />
A plugin is made up of a Python module with one default exported function, that takes two deconstructed object parameters: <code>widgets</code> and <code>simulator</code>. Both are described in the following:<br />
<br />
==Widgets==<br />
<code>widgets</code> has one method, <code>register</code> that allows you to register widgets that can used by all the prototypes in the model through the '''Widgets Config''':<br />
<br />
<code><br />
register(widget_name: string, onActivate: (container: Container) => undefined | WidgetDeactivateFunction) => undefined<br />
</code><br />
<br />
===Container===<br />
Container has 3 properties:<br />
<br />
{| class="wikitable"<br />
|-<br />
! # !! Argument !! Description<br />
|-<br />
| 1 || <code>injectHTML(html: string) => void</code>|| <code>injectHTML</code> is used to inject html in the box, essentially setting its <code>innerHTML</code>.<br />
|-<br />
| 2 || <code>injectNode(node: Node) => void</code> || <code>injectNode</code> is used to inject an HTML Node (element or fragment) in the box. This is usually needed for complex use cases that <code>injectHTML</code> can't be used for, like event listeners.<br />
|-<br />
| 3 || window || The window object of the container iframe.<br />
|}<br />
<br />
===WidgetDeactivateFunction() => void===<br />
The deactivate function is executed whenever a widget is removed from the grid. This is useful for clearing stuff such as<br />
intervals<br />
<br />
==Simulator==<br />
<code><br />
simulator(api: string, method: "get" | "set" | "subscribe", func: SimulatorModifier) => void<br />
</code><br />
<br />
<code>simulator</code> is a function that let's you override any VSS API's get , set and subscribe methods<br />
<br />
It accepts 3 parameters:<br />
# <code>api</code>: The name of the VSS API to override, for example: Vehicle.Body.Hood.IsOpen<br />
# <code>method</code>: The method to override, this can be only one of get, set, or subscribe.<br />
# <code>func</code>: The modifier that is run when the API method is called, of SimulatorModifier type<br />
<br />
<code>SimulatorModifer</code> is called with two deconstructed object parameters:<br />
# <code>args: any[]</code>: Array of arguments passed in the Python code to the method, converted to equivalent JS types.<br />
# <code>prevReturnValue: any</code>: The return value this method would return if the prevReturnValue is undefined.<br />
Multiple plugins can each attach multiple modifiers to a method, all these modifiers will be called in the same order they were<br />
attached.<br />
<br />
The return value of the previous modifier will be passed to <code>prevReturnValue</code>.<br />
<br />
==Widgets Config==<br />
The widgets config is a JSON array of <code>GridItem</code> objects specified in the code tab of the prototype.<br />
<br />
GridItem has 3 properties:<br />
# <code>boxes: number[]</code>: The boxes this grid item should occupy. Boxes must be adjacent (horizontally or vertically) and for<br />
now, a grid item can occupy a maximum of 2 boxes.<br />
# <code>plugin: string</code>: The name of the plugin for this widget. This is the plugin name specified when creating a plugin.<br />
# <code>widget: string</code>: The widget name. This is specified in the plugin code when registering a widget<br />
<br />
= Summary =<br />
The following provides an overview of all elements involved: A vehicle model in the playground includes one instance of a VSS catalogue (e.g. the YAML definition file with all the VSS definitions), n number of plugin implementations, and n number of SdV prototypes. <br />
<br />
The VSS catalogue can be extended to use VSS Wishlist items, defined ad-hoc by different prototypes. digital.auto and COVESA are currently working on a way to submit items from the VSS Wishlist to the COVESA process for standardization of VSS.<br />
<br />
Plugins are defining simulators and widgets. Widgets are providing the UX for simulators (defined in the same of other plugins). In the future, each plugin will be associated with one SdV prototype for documentation purposes, as well as for defining the VSS wishlist APIs which might be required by the plugin.<br />
<br />
SdV prototypes are using plugins. In order to use a plugin, the configuration will have to state where exactly the required widgets should be played on the prototype-specific version of the playground grid.<br />
<br />
[[File:All Playground Elements.png|800px|frameless|center|All Playground Elements]]</div>Adminhttps://www.digitalplaybook.org/index.php?title=Documentation:_playground.digital.auto&diff=7745Documentation: playground.digital.auto2022-11-18T16:42:08Z<p>Admin: </p>
<hr />
<div>[[File:Playground.png|2000px|frameless|center|playground.digital.auto]]<br />
<s data-category="DigitalAuto"></s><br />
<br />
This page provides developer documentation for the digital.auto playground, a web-based, rapid prototyping environment for the Software-defined Vehicle with standardized vehicle APIs. Also check out the following resources:<br />
* [https://drive.google.com/file/d/1qYfakx6E592PWBtPzAc_m_LrmBsvaI9K/view?usp=share_link Overview video] of digital.auto playground<br />
* [https://drive.google.com/file/d/1Z-tv5COhmX-lQGtHMSUZWLuvv5PoFAFR/view?usp=share_link Introduction] to digital.auto playground plugin development<br />
* digital.auto playground [https://playground-plugins.netlify.app/ widget documentation]<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
The digital.auto playground provides automotive software developers and product managers with an environment to rapidly develop prototypes for the Software-defined Vehicle (SdV). The environment is purely web-based. Prototypes are developed in Python. To interact with vehicle sensors and actuators, the COVESA [https://wiki.covesa.global/display/WIK4/VSS+-+Vehicle+Signal+Specification Vehicle Signal Specification (VSS)] is used. In the browser environment of the playground, the vehicle sensors and actuators are mocked, using simple test values. Access to VSS in Python is provided via the emerging VSS Python mapping, as defined by the [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas] project (part of [https://sdv.eclipse.org/ Eclipse SdV]). As we will discuss in the following, access to more sophisticated vehicle simulation environments or even real sensors and actuators is possible via a cloud bridge mechanism.<br />
<br />
=The value of early prototyping=<br />
<br />
The digital.project is promoting a digital-first approach to vehicle development: Develop the vehicle software and applications as early as possible, instead of after the hardware and physical vehicle design. This approach has two main benefits: First, early customer feedback helps to learn which ideas have highest potential for customer value creation. This helps minimizing investments in unpopular features. Fine-tuning the customer journey design early is key for customer acceptance. Of course this does not mean that the software should not constantly be improved later on, even after the Start of Production. After all, this is why DevOps pipelines with OTA for remote vehicle updates are currently being established.<br />
<br />
Second, doing early prototyping also has many benefits from the development perspective: Having a functional mockup early on in the development cycle helps improving transparency between business/IT, across regional and organizational boundaries. If also helps to validate architecture decisions early on, as well as to have a consistent enterprise architecture across all features. Finally, being able to identify API requirements as early as possible is key, because providing an API which encapsulates hardware usually has a very long lead time. This is especially true for hardware and APIs coming from external suppliers.<br />
<br />
[[File:Value of early prototyping.png|800px|frameless|center|Value of early prototyping]]<br />
<br />
=digital.auto value streams=<br />
The following is looking at both, the digital and physical value stream in digital.auto, followed by a discussion of the evolution of code in the digital value stream.<br />
<br />
==Digital and physical value stream==<br />
The digital.auto playground is designed to support the general philosophy of digital.auto, which is assuming two distinct value streams, moving at different speeds: The physical and the digital value stream. These two value streams are de-coupled via a Hardware Abstraction Layer (HAL), which is encapsulating the complexities of vehicle physics, embedded systems, and bus systems. Software components developed in the digital value stream are accessing vehicle functions via well defined interfaces (e.g. VSS). This de-coupling allows components north and south of the API to be (more or less) seamlessly interchanged. For example, a prototype in the playground can first run against simple test values provided by VSS mock implementations in the playground. Next, one might plug in a real vehicle simulation, running south of the API, and providing a more realistic system behavior. Finally, the simulation will be replaced by hardware with real sensors and actuators - starting with a breadboard, and eventually the final vehicle. <br />
<br />
[[File:Value Streams.png|800px|frameless|center|Value Streams]]<br />
<br />
Similarly, north of the API, new SdV features can initially be developed in Python in the playground. Next, the SdV prototype code can be deployed to a professional development environment - as provided, for example, by [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas]. In this environment, the new SdV feature can first be tested in the cloud, before finally being deployed on a vehicle computer.<br />
<br />
==Code evolution in the digital value stream==<br />
<br />
In order for the SdV code not to break when moving from the playground to the real development environment, the VSS Python APIs are currently being standardized by the Eclipse community. This allows to migrate code more easily between different environments. For example, as described in the figure below, an SdV function might initially be implemented as a prototype in the digital.auto playground. After the initial customer validation, the decision is made to migrate the code from the prototyping environment to the professional development environment, including proper support for CI/CD. This can be done easily because of the standardization of the Python APIs. In fact, the next release of the playground will have built-in support to deploy into Eclipse Velocitas by creating a complete Velocitas project in GitHub, based on the initial prototype.<br />
<br />
[[File:Deployment and code evolution.png|450px|frameless|center|Deployment and code evolution]]<br />
<br />
One important note: Even if the final target language for the production system is not Python - but maybe C++ or Rust - having a Python prototype for early vehicle tests is extremely valuable, because it helps getting an end-to-end implementation done quickly, and stabilizing the APIs between the distributed components.<br />
<br />
= VSS Python API =<br />
<br />
The VSS API is organized in a strict tree hierarchy. The nodes of the VSS tree are called branches. The leaves in the tree are representing sensors, actuators, and attributes. An example for a sensor representation in VSS looks like this:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.IsBelted</code><br />
<br />
This VSS API or data point will return a boolean value, indicating whether the belt is engaged. Please note that the VSS API catalogue can be adapted for individual vehicle instances - for example, supporting vehicles with different numbers of seat rows.<br />
<br />
An example for an actuator in VSS is shown in the following:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline</code><br />
<br />
This API will control the seat z-axis depends on seat tilt.<br />
<br />
==get()/set() functions==<br />
<br />
Using the VSS API in Python is straight forward. For example, to get the current state of a seat belt, the following code can be used:<br />
<br />
<code><br />
from ACME_Car_EV_v01 import Vehicle<br><br />
vehicle = Vehicle()<br><br />
vehicle.Cabin.Seat.Row1.Pos1.IsBelted.get()<br><br />
</code><br />
<br />
The <code>get()</code> function will simply return the current state of the <code>IsBelted</code> sensor represented by the corresponding Python object in the digital.auto playground library.<br />
<br />
Not very surprisingly, to control an actuator, a <code>set()</code> API is provided in Pyhton, e.g.:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.set(25)<br />
</code><br />
<br />
However, as straight-forward as this code actually looks like, the logic behind it is not as straight forward - the reason being that this API is supposed to control a physical device, which might not react immediately to the request (or maybe not at all). From the [https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/sensor_actuator/ VSS specification]: ''“Actuators are used to control the desired value of a property. Some properties in a vehicle cannot change instantly. A typical example is position of a seat or a window. Reading a value of an actuator shall return the current actual value, e.g. the current position of the seat, rather than the wanted/desired position. A typical example could be if someone wants to change the position of a seat from 0 to 100. This can be changed by setting the corresponding actuator to 100. If the actuator is read directly after the set request it will still return 0 as it might take some seconds before the seat reaches the wanted position of 100. If the seat by some reason is blocked or cannot be moved due to safety reasons it might never reach the wanted position. It is up to the vehicle to decide how long time it shall try to reach the desired value and what to do if it needs to give up.”'' <br />
<br />
Even though <code>BackrestRecline</code> is encapsulating an actuator, its current value can be read using <code>get()</code>:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.get()<br />
</code><br />
<br />
However, as per the above discussing please note that it might not be 100% clear what the return value is actually indicating. Note that there is work going on at the moment to support APIs which differentiate between the actual value vs the intended value of an actuator.<br />
<br />
Finally, please also note that the current version of VSS used here is not supporting meta data in the API that could be used to support additional service level, including real-time requirements, request priorization, etc. This means that the SdV code using VSS currently is aiming at applications which are labeled as "QM", according to the [https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level ASIL] standard - meaning the code does not support any of the higher ASIL safety levels, such as ASIL A, B, C or D.<br />
<br />
== Event listeners ==<br />
When dealing with sensor data - even for mocked sensors - it can often make sense to use a more event-driven model, instead of constantly polling the sensor. To support this, the Python API for VSS is supporting a simple event-driven programming model. Using the <code>subscribe()</code> method, a callback function can be associated with a sensor. This function will be called every time a new value is available.<br />
<br />
In the following code sample, a new function <code>on_hood_is_open_changed</code> is defined, and then associated with <code>vehicle.Body.Hood.IsOpen</code> via the <code>subscribe()</code> method. After this, a mock wiper is turned on to MEDIUM speed. Next, the mock hood is opened. This will result in <code>on_hood_is_open_changed</code> being called, which in turn will turn the wipers off.<br />
<br />
<code><br />
def on_hood_is_open_changed(IsOpen: bool):<br />
if IsOpen:<br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.OFF)<br />
vehicle.Body.Hood.IsOpen.subscribe(on_hood_is_open_changed)<br><br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.MEDIUM)<br><br />
vehicle.Body.Hood.IsOpen.set(True)<br><br />
</code><br />
<br />
=Playground architecture=<br />
The following provides an overview of the playground architecture, as well as the key elements of the plugin concept.<br />
<br />
==Overview==<br />
The digital.auto playground is designed to allow execution of SdV Python code against the standard VSS Python API. The SdV Python code is executed in the browser, against a set of Python objects representing the VSS API. To ensure a good user experience, the playground also has to support easy manipulation of the HTML Document Object Model (DOM), as well as remote interaction with the cloud. Since most browser development is done in JavaScript these days, the playground supports a plug-in mechanism which is implemented in JavaScript. This means that the SdV Prototypes in Pyhton are really interacting with VSS objects which are implemented in JavaScript. This way, a vehicle mockup can easily be built using browser-native tools. The mechanism used here is a Python-to-JavaScript bridge, which is translating between the SdV functions in Python and the plug-ins in JavaScript. <br />
<br />
[[File:Playground Architecture.png|800px|frameless|center|Playground Architecture]]<br />
<br />
==Playground plugins==<br />
<br />
Plugins for the digital.auto playground are usually providing a mockup and a visualization of a specific vehicle feature, exposed via VSS. An example could be a Google maps plugin, which is visualizing the vehicle's current position by accessing <code>Vehicle.CurrentLocation</code>.<br />
<br />
A plugin can provide two things:<br />
* Widget which are providing the UX to visualize the behavior represented by one or more VSS APIs<br />
* Simulators which are implementing VSS APIs<br />
<br />
An SdV prototype that wants to make use of a plugin must do two things:<br />
* Import the plugin Python library<br />
* Configure the plugins used (especially the UX layout)<br />
<br />
Plugins can be combined in different ways. For example, an SdV prototype might import the Google maps plugin to visualize the vehicle`s position on a map, plus another plugin which is actually implementing <code>Vehicle.CurrentLocation</code>. Or, the UX and the VSS implementation might be combined in one plugin, depending on the design.<br />
<br />
[[File:Plugin Overview.png|800px|frameless|center|Plugin Overview]]<br />
<br />
The digital.auto project is aiming to build up a rich plug-in library over time.<br />
However, often it will be required to implement dedicated plugins for a specific prototype.<br />
To support this, the plugin mechanism in the playground is open, both for plugin consumption as well as provisioning.<br />
<br />
For the implementer of a plugin, the following provides more detailed instructions for doing so.<br />
<br />
==Simulators==<br />
By default, the VSS Python API is providing an implementation which provides a very basic functionality: the <code>get()</code> functions are returning the current value (initialized randomly). The <code>set()</code> functions are storing the value passed to them.<br />
<br />
Simulators are providing a way to change this functionality. They allow plug-in developers to implement more specific functions for a given VSS sensors, actuator, or attribute. For example, a get function could communicate with a remote service in the cloud to receive the current sensor value. This can be any cloud, assuming that Cross-Origin Resource Sharing (CORS) or an alternative mechanism is used.<br />
<br />
A simulator can also be combined with a widget, e.g. to visualize a new sensor value.<br />
<br />
==Widgets==<br />
Widgets can use the built-in grid area of the playground to visualize vehicle functions, or even provide an interactive experience - using standard browser functionality. The grid is divided into 5x2 grid cells. A widget can occupy 1 or more grid cells, always assuming a rectangular shape.<br />
<br />
The grid mechanism is designed as simple as possible (we wanted to avoid the complexities of a full-blown portal server), yet giving a lot of flexibility. Each widget is mapped to an iFrame, meaning that a widget can use all functionalities which an iFrame supports.<br />
<br />
When designing a widget, using the right size must be ensured. For example, the ideal size for a 2x1 box video in the grid would be: 1080x756<br />
<br />
It doesn't need to be exact, but<br />
* Any size smaller would need to be centered, with space on all sides.<br />
* Any size larger would appear the exact same, but would take more time to load.<br />
* Any change in ratio would mean extra space (either horizontally or vertically)<br />
<br />
==Default Widget Style==<br />
Ideally, different widgets should use a similar style, so that if multiple widgets from different source are combined, they provide a consistent use experience. To achieve this, digital.auto recommends the following:<br />
* Use the following font: https://www.w3schools.com/cssref/css_websafe_fonts.php<br />
* Use only the colors defined on the following table, plus black/white<br />
<br />
[[File:Digital.auto colors.png|800px|frameless|center|digital.auto colors]]<br />
<br />
= Using plugins=<br />
In order to use a plugin, it needs to be imported and configured. The configuration is necessary so that the playground understands which prototypes should be used, and how to map them to the playground`s grid-based widget layout. The following example is configuring the use of two plugins, InstrumentPanel and SmartPhone:<br />
<br />
<code><br />
[<br><br />
{<br><br />
"boxes": [2, 3],<br><br />
"plugin": "InstrumentPanel",<br><br />
"widget": "Speedometer"<br><br />
},<br><br />
{<br><br />
"boxes": [1],<br><br />
"plugin": "SmartPhone",<br><br />
"widget": "Image"<br><br />
}<br><br />
]<br></code><br />
<br />
In this example, SmartPhone will occupy the first position in the playground grid, the Instrument panel the 2nd and 3rd.<br />
<br />
In order now to use these plugins in Python, the SdV prototype has to import <code>plugins</code>, like in the following example:<br />
<br />
<code><br />
from ACME_Car_ICE_v01 import Vehicle<br><br />
import plugins<br><br />
<br />
plugins.SmartPhone.set_text("Added text to SmartPhone")<br><br />
<br />
vehicle = Vehicle()<br><br />
<br />
await vehicle.Cabin.InstrumentPanel.Status.set(f"TEXT IN InstrumentPanel")<br><br />
<br />
</code><br />
<br />
In this example, a text is added via a proprietary API to a the mockup of a Smart Phone. This is because a Smart Phone is not part of VSS.<br />
Next, a text is added to <code>Vehicle.Cabin.InstrumentPanel.Status</code>. In this case, <code>InstrumentPanel.Status</code> was added to the VSS API as a Wishlist-Item, because this could actually make sense from a VSS perspective.<br />
<br />
= Implementing plugins=<br />
A plugin is made up of a Python module with one default exported function, that takes two deconstructed object parameters: <code>widgets</code> and <code>simulator</code>. Both are described in the following:<br />
<br />
==Widgets==<br />
<code>widgets</code> has one method, <code>register</code> that allows you to register widgets that can used by all the prototypes in the model through the '''Widgets Config''':<br />
<br />
<code><br />
register(widget_name: string, onActivate: (container: Container) => undefined | WidgetDeactivateFunction) => undefined<br />
</code><br />
<br />
===Container===<br />
Container has 3 properties:<br />
<br />
{| class="wikitable"<br />
|-<br />
! # !! Argument !! Description<br />
|-<br />
| 1 || <code>injectHTML(html: string) => void</code>|| <code>injectHTML</code> is used to inject html in the box, essentially setting its <code>innerHTML</code>.<br />
|-<br />
| 2 || <code>injectNode(node: Node) => void</code> || <code>injectNode</code> is used to inject an HTML Node (element or fragment) in the box. This is usually needed for complex use cases that <code>injectHTML</code> can't be used for, like event listeners.<br />
|-<br />
| 3 || window || The window object of the container iframe.<br />
|}<br />
<br />
===WidgetDeactivateFunction() => void===<br />
The deactivate function is executed whenever a widget is removed from the grid. This is useful for clearing stuff such as<br />
intervals<br />
<br />
==Simulator==<br />
<code><br />
simulator(api: string, method: "get" | "set" | "subscribe", func: SimulatorModifier) => void<br />
</code><br />
<br />
<code>simulator</code> is a function that let's you override any VSS API's get , set and subscribe methods<br />
<br />
It accepts 3 parameters:<br />
# <code>api</code>: The name of the VSS API to override, for example: Vehicle.Body.Hood.IsOpen<br />
# <code>method</code>: The method to override, this can be only one of get, set, or subscribe.<br />
# <code>func</code>: The modifier that is run when the API method is called, of SimulatorModifier type<br />
<br />
<code>SimulatorModifer</code> is called with two deconstructed object parameters:<br />
# <code>args: any[]</code>: Array of arguments passed in the Python code to the method, converted to equivalent JS types.<br />
# <code>prevReturnValue: any</code>: The return value this method would return if the prevReturnValue is undefined.<br />
Multiple plugins can each attach multiple modifiers to a method, all these modifiers will be called in the same order they were<br />
attached.<br />
<br />
The return value of the previous modifier will be passed to <code>prevReturnValue</code>.<br />
<br />
==Widgets Config==<br />
The widgets config is a JSON array of <code>GridItem</code> objects specified in the code tab of the prototype.<br />
<br />
GridItem has 3 properties:<br />
# <code>boxes: number[]</code>: The boxes this grid item should occupy. Boxes must be adjacent (horizontally or vertically) and for<br />
now, a grid item can occupy a maximum of 2 boxes.<br />
# <code>plugin: string</code>: The name of the plugin for this widget. This is the plugin name specified when creating a plugin.<br />
# <code>widget: string</code>: The widget name. This is specified in the plugin code when registering a widget<br />
<br />
= Summary =<br />
The following provides an overview of all elements involved: A vehicle model in the playground includes one instance of a VSS catalogue (e.g. the YAML definition file with all the VSS definitions), n number of plugin implementations, and n number of SdV prototypes. <br />
<br />
The VSS catalogue can be extended to use VSS Wishlist items, defined ad-hoc by different prototypes. digital.auto and COVESA are currently working on a way to submit items from the VSS Wishlist to the COVESA process for standardization of VSS.<br />
<br />
Plugins are defining simulators and widgets. Widgets are providing the UX for simulators (defined in the same of other plugins). In the future, each plugin will be associated with one SdV prototype for documentation purposes, as well as for defining the VSS wishlist APIs which might be required by the plugin.<br />
<br />
SdV prototypes are using plugins. In order to use a plugin, the configuration will have to state where exactly the required widgets should be played on the prototype-specific version of the playground grid.<br />
<br />
[[File:All Playground Elements.png|800px|frameless|center|All Playground Elements]]</div>Adminhttps://www.digitalplaybook.org/index.php?title=Documentation:_playground.digital.auto&diff=7744Documentation: playground.digital.auto2022-11-18T16:36:50Z<p>Admin: </p>
<hr />
<div>[[File:Playground.png|2000px|frameless|center|playground.digital.auto]]<br />
<s data-category="DigitalAuto"></s><br />
<br />
This page provides developer documentation for the digital.auto playground, a web-based, rapid prototyping environment for the Software-defined Vehicle with standardized vehicle APIs.<br />
<br />
__TOC__<br />
<br />
=Overview=<br />
<br />
The digital.auto playground provides automotive software developers and product managers with an environment to rapidly develop prototypes for the Software-defined Vehicle (SdV). The environment is purely web-based. Prototypes are developed in Python. To interact with vehicle sensors and actuators, the COVESA [https://wiki.covesa.global/display/WIK4/VSS+-+Vehicle+Signal+Specification Vehicle Signal Specification (VSS)] is used. In the browser environment of the playground, the vehicle sensors and actuators are mocked, using simple test values. Access to VSS in Python is provided via the emerging VSS Python mapping, as defined by the [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas] project (part of [https://sdv.eclipse.org/ Eclipse SdV]). As we will discuss in the following, access to more sophisticated vehicle simulation environments or even real sensors and actuators is possible via a cloud bridge mechanism.<br />
<br />
=The value of early prototyping=<br />
<br />
The digital.project is promoting a digital-first approach to vehicle development: Develop the vehicle software and applications as early as possible, instead of after the hardware and physical vehicle design. This approach has two main benefits: First, early customer feedback helps to learn which ideas have highest potential for customer value creation. This helps minimizing investments in unpopular features. Fine-tuning the customer journey design early is key for customer acceptance. Of course this does not mean that the software should not constantly be improved later on, even after the Start of Production. After all, this is why DevOps pipelines with OTA for remote vehicle updates are currently being established.<br />
<br />
Second, doing early prototyping also has many benefits from the development perspective: Having a functional mockup early on in the development cycle helps improving transparency between business/IT, across regional and organizational boundaries. If also helps to validate architecture decisions early on, as well as to have a consistent enterprise architecture across all features. Finally, being able to identify API requirements as early as possible is key, because providing an API which encapsulates hardware usually has a very long lead time. This is especially true for hardware and APIs coming from external suppliers.<br />
<br />
[[File:Value of early prototyping.png|800px|frameless|center|Value of early prototyping]]<br />
<br />
=digital.auto value streams=<br />
The following is looking at both, the digital and physical value stream in digital.auto, followed by a discussion of the evolution of code in the digital value stream.<br />
<br />
==Digital and physical value stream==<br />
The digital.auto playground is designed to support the general philosophy of digital.auto, which is assuming two distinct value streams, moving at different speeds: The physical and the digital value stream. These two value streams are de-coupled via a Hardware Abstraction Layer (HAL), which is encapsulating the complexities of vehicle physics, embedded systems, and bus systems. Software components developed in the digital value stream are accessing vehicle functions via well defined interfaces (e.g. VSS). This de-coupling allows components north and south of the API to be (more or less) seamlessly interchanged. For example, a prototype in the playground can first run against simple test values provided by VSS mock implementations in the playground. Next, one might plug in a real vehicle simulation, running south of the API, and providing a more realistic system behavior. Finally, the simulation will be replaced by hardware with real sensors and actuators - starting with a breadboard, and eventually the final vehicle. <br />
<br />
[[File:Value Streams.png|800px|frameless|center|Value Streams]]<br />
<br />
Similarly, north of the API, new SdV features can initially be developed in Python in the playground. Next, the SdV prototype code can be deployed to a professional development environment - as provided, for example, by [https://projects.eclipse.org/projects/automotive.velocitas Eclipse Velocitas]. In this environment, the new SdV feature can first be tested in the cloud, before finally being deployed on a vehicle computer.<br />
<br />
==Code evolution in the digital value stream==<br />
<br />
In order for the SdV code not to break when moving from the playground to the real development environment, the VSS Python APIs are currently being standardized by the Eclipse community. This allows to migrate code more easily between different environments. For example, as described in the figure below, an SdV function might initially be implemented as a prototype in the digital.auto playground. After the initial customer validation, the decision is made to migrate the code from the prototyping environment to the professional development environment, including proper support for CI/CD. This can be done easily because of the standardization of the Python APIs. In fact, the next release of the playground will have built-in support to deploy into Eclipse Velocitas by creating a complete Velocitas project in GitHub, based on the initial prototype.<br />
<br />
[[File:Deployment and code evolution.png|450px|frameless|center|Deployment and code evolution]]<br />
<br />
One important note: Even if the final target language for the production system is not Python - but maybe C++ or Rust - having a Python prototype for early vehicle tests is extremely valuable, because it helps getting an end-to-end implementation done quickly, and stabilizing the APIs between the distributed components.<br />
<br />
= VSS Python API =<br />
<br />
The VSS API is organized in a strict tree hierarchy. The nodes of the VSS tree are called branches. The leaves in the tree are representing sensors, actuators, and attributes. An example for a sensor representation in VSS looks like this:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.IsBelted</code><br />
<br />
This VSS API or data point will return a boolean value, indicating whether the belt is engaged. Please note that the VSS API catalogue can be adapted for individual vehicle instances - for example, supporting vehicles with different numbers of seat rows.<br />
<br />
An example for an actuator in VSS is shown in the following:<br />
<br />
<code>Vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline</code><br />
<br />
This API will control the seat z-axis depends on seat tilt.<br />
<br />
==get()/set() functions==<br />
<br />
Using the VSS API in Python is straight forward. For example, to get the current state of a seat belt, the following code can be used:<br />
<br />
<code><br />
from ACME_Car_EV_v01 import Vehicle<br><br />
vehicle = Vehicle()<br><br />
vehicle.Cabin.Seat.Row1.Pos1.IsBelted.get()<br><br />
</code><br />
<br />
The <code>get()</code> function will simply return the current state of the <code>IsBelted</code> sensor represented by the corresponding Python object in the digital.auto playground library.<br />
<br />
Not very surprisingly, to control an actuator, a <code>set()</code> API is provided in Pyhton, e.g.:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.set(25)<br />
</code><br />
<br />
However, as straight-forward as this code actually looks like, the logic behind it is not as straight forward - the reason being that this API is supposed to control a physical device, which might not react immediately to the request (or maybe not at all). From the [https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/sensor_actuator/ VSS specification]: ''“Actuators are used to control the desired value of a property. Some properties in a vehicle cannot change instantly. A typical example is position of a seat or a window. Reading a value of an actuator shall return the current actual value, e.g. the current position of the seat, rather than the wanted/desired position. A typical example could be if someone wants to change the position of a seat from 0 to 100. This can be changed by setting the corresponding actuator to 100. If the actuator is read directly after the set request it will still return 0 as it might take some seconds before the seat reaches the wanted position of 100. If the seat by some reason is blocked or cannot be moved due to safety reasons it might never reach the wanted position. It is up to the vehicle to decide how long time it shall try to reach the desired value and what to do if it needs to give up.”'' <br />
<br />
Even though <code>BackrestRecline</code> is encapsulating an actuator, its current value can be read using <code>get()</code>:<br />
<br />
<code><br />
vehicle.Cabin.Seat.Row1.Pos1.BackrestRecline.get()<br />
</code><br />
<br />
However, as per the above discussing please note that it might not be 100% clear what the return value is actually indicating. Note that there is work going on at the moment to support APIs which differentiate between the actual value vs the intended value of an actuator.<br />
<br />
Finally, please also note that the current version of VSS used here is not supporting meta data in the API that could be used to support additional service level, including real-time requirements, request priorization, etc. This means that the SdV code using VSS currently is aiming at applications which are labeled as "QM", according to the [https://en.wikipedia.org/wiki/Automotive_Safety_Integrity_Level ASIL] standard - meaning the code does not support any of the higher ASIL safety levels, such as ASIL A, B, C or D.<br />
<br />
== Event listeners ==<br />
When dealing with sensor data - even for mocked sensors - it can often make sense to use a more event-driven model, instead of constantly polling the sensor. To support this, the Python API for VSS is supporting a simple event-driven programming model. Using the <code>subscribe()</code> method, a callback function can be associated with a sensor. This function will be called every time a new value is available.<br />
<br />
In the following code sample, a new function <code>on_hood_is_open_changed</code> is defined, and then associated with <code>vehicle.Body.Hood.IsOpen</code> via the <code>subscribe()</code> method. After this, a mock wiper is turned on to MEDIUM speed. Next, the mock hood is opened. This will result in <code>on_hood_is_open_changed</code> being called, which in turn will turn the wipers off.<br />
<br />
<code><br />
def on_hood_is_open_changed(IsOpen: bool):<br />
if IsOpen:<br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.OFF)<br />
vehicle.Body.Hood.IsOpen.subscribe(on_hood_is_open_changed)<br><br />
vehicle.Body.Windshield.Front.Wiping.Mode.set(vehicle.Body.Windshield.Front.Wiping.Mode.MEDIUM)<br><br />
vehicle.Body.Hood.IsOpen.set(True)<br><br />
</code><br />
<br />
=Playground architecture=<br />
The following provides an overview of the playground architecture, as well as the key elements of the plugin concept.<br />
<br />
==Overview==<br />
The digital.auto playground is designed to allow execution of SdV Python code against the standard VSS Python API. The SdV Python code is executed in the browser, against a set of Python objects representing the VSS API. To ensure a good user experience, the playground also has to support easy manipulation of the HTML Document Object Model (DOM), as well as remote interaction with the cloud. Since most browser development is done in JavaScript these days, the playground supports a plug-in mechanism which is implemented in JavaScript. This means that the SdV Prototypes in Pyhton are really interacting with VSS objects which are implemented in JavaScript. This way, a vehicle mockup can easily be built using browser-native tools. The mechanism used here is a Python-to-JavaScript bridge, which is translating between the SdV functions in Python and the plug-ins in JavaScript. <br />
<br />
[[File:Playground Architecture.png|800px|frameless|center|Playground Architecture]]<br />
<br />
==Playground plugins==<br />
<br />
Plugins for the digital.auto playground are usually providing a mockup and a visualization of a specific vehicle feature, exposed via VSS. An example could be a Google maps plugin, which is visualizing the vehicle's current position by accessing <code>Vehicle.CurrentLocation</code>.<br />
<br />
A plugin can provide two things:<br />
* Widget which are providing the UX to visualize the behavior represented by one or more VSS APIs<br />
* Simulators which are implementing VSS APIs<br />
<br />
An SdV prototype that wants to make use of a plugin must do two things:<br />
* Import the plugin Python library<br />
* Configure the plugins used (especially the UX layout)<br />
<br />
Plugins can be combined in different ways. For example, an SdV prototype might import the Google maps plugin to visualize the vehicle`s position on a map, plus another plugin which is actually implementing <code>Vehicle.CurrentLocation</code>. Or, the UX and the VSS implementation might be combined in one plugin, depending on the design.<br />
<br />
[[File:Plugin Overview.png|800px|frameless|center|Plugin Overview]]<br />
<br />
The digital.auto project is aiming to build up a rich plug-in library over time.<br />
However, often it will be required to implement dedicated plugins for a specific prototype.<br />
To support this, the plugin mechanism in the playground is open, both for plugin consumption as well as provisioning.<br />
<br />
For the implementer of a plugin, the following provides more detailed instructions for doing so.<br />
<br />
==Simulators==<br />
By default, the VSS Python API is providing an implementation which provides a very basic functionality: the <code>get()</code> functions are returning the current value (initialized randomly). The <code>set()</code> functions are storing the value passed to them.<br />
<br />
Simulators are providing a way to change this functionality. They allow plug-in developers to implement more specific functions for a given VSS sensors, actuator, or attribute. For example, a get function could communicate with a remote service in the cloud to receive the current sensor value. This can be any cloud, assuming that Cross-Origin Resource Sharing (CORS) or an alternative mechanism is used.<br />
<br />
A simulator can also be combined with a widget, e.g. to visualize a new sensor value.<br />
<br />
==Widgets==<br />
Widgets can use the built-in grid area of the playground to visualize vehicle functions, or even provide an interactive experience - using standard browser functionality. The grid is divided into 5x2 grid cells. A widget can occupy 1 or more grid cells, always assuming a rectangular shape.<br />
<br />
The grid mechanism is designed as simple as possible (we wanted to avoid the complexities of a full-blown portal server), yet giving a lot of flexibility. Each widget is mapped to an iFrame, meaning that a widget can use all functionalities which an iFrame supports.<br />
<br />
When designing a widget, using the right size must be ensured. For example, the ideal size for a 2x1 box video in the grid would be: 1080x756<br />
<br />
It doesn't need to be exact, but<br />
* Any size smaller would need to be centered, with space on all sides.<br />
* Any size larger would appear the exact same, but would take more time to load.<br />
* Any change in ratio would mean extra space (either horizontally or vertically)<br />
<br />
==Default Widget Style==<br />
Ideally, different widgets should use a similar style, so that if multiple widgets from different source are combined, they provide a consistent use experience. To achieve this, digital.auto recommends the following:<br />
* Use the following font: https://www.w3schools.com/cssref/css_websafe_fonts.php<br />
* Use only the colors defined on the following table, plus black/white<br />
<br />
[[File:Digital.auto colors.png|800px|frameless|center|digital.auto colors]]<br />
<br />
= Using plugins=<br />
In order to use a plugin, it needs to be imported and configured. The configuration is necessary so that the playground understands which prototypes should be used, and how to map them to the playground`s grid-based widget layout. The following example is configuring the use of two plugins, InstrumentPanel and SmartPhone:<br />
<br />
<code><br />
[<br><br />
{<br><br />
"boxes": [2, 3],<br><br />
"plugin": "InstrumentPanel",<br><br />
"widget": "Speedometer"<br><br />
},<br><br />
{<br><br />
"boxes": [1],<br><br />
"plugin": "SmartPhone",<br><br />
"widget": "Image"<br><br />
}<br><br />
]<br></code><br />
<br />
In this example, SmartPhone will occupy the first position in the playground grid, the Instrument panel the 2nd and 3rd.<br />
<br />
In order now to use these plugins in Python, the SdV prototype has to import <code>plugins</code>, like in the following example:<br />
<br />
<code><br />
from ACME_Car_ICE_v01 import Vehicle<br><br />
import plugins<br><br />
<br />
plugins.SmartPhone.set_text("Added text to SmartPhone")<br><br />
<br />
vehicle = Vehicle()<br><br />
<br />
await vehicle.Cabin.InstrumentPanel.Status.set(f"TEXT IN InstrumentPanel")<br><br />
<br />
</code><br />
<br />
In this example, a text is added via a proprietary API to a the mockup of a Smart Phone. This is because a Smart Phone is not part of VSS.<br />
Next, a text is added to <code>Vehicle.Cabin.InstrumentPanel.Status</code>. In this case, <code>InstrumentPanel.Status</code> was added to the VSS API as a Wishlist-Item, because this could actually make sense from a VSS perspective.<br />
<br />
= Implementing plugins=<br />
A plugin is made up of a Python module with one default exported function, that takes two deconstructed object parameters: <code>widgets</code> and <code>simulator</code>. Both are described in the following:<br />
<br />
==Widgets==<br />
<code>widgets</code> has one method, <code>register</code> that allows you to register widgets that can used by all the prototypes in the model through the '''Widgets Config''':<br />
<br />
<code><br />
register(widget_name: string, onActivate: (container: Container) => undefined | WidgetDeactivateFunction) => undefined<br />
</code><br />
<br />
===Container===<br />
Container has 3 properties:<br />
<br />
{| class="wikitable"<br />
|-<br />
! # !! Argument !! Description<br />
|-<br />
| 1 || <code>injectHTML(html: string) => void</code>|| <code>injectHTML</code> is used to inject html in the box, essentially setting its <code>innerHTML</code>.<br />
|-<br />
| 2 || <code>injectNode(node: Node) => void</code> || <code>injectNode</code> is used to inject an HTML Node (element or fragment) in the box. This is usually needed for complex use cases that <code>injectHTML</code> can't be used for, like event listeners.<br />
|-<br />
| 3 || window || The window object of the container iframe.<br />
|}<br />
<br />
===WidgetDeactivateFunction() => void===<br />
The deactivate function is executed whenever a widget is removed from the grid. This is useful for clearing stuff such as<br />
intervals<br />
<br />
==Simulator==<br />
<code><br />
simulator(api: string, method: "get" | "set" | "subscribe", func: SimulatorModifier) => void<br />
</code><br />
<br />
<code>simulator</code> is a function that let's you override any VSS API's get , set and subscribe methods<br />
<br />
It accepts 3 parameters:<br />
# <code>api</code>: The name of the VSS API to override, for example: Vehicle.Body.Hood.IsOpen<br />
# <code>method</code>: The method to override, this can be only one of get, set, or subscribe.<br />
# <code>func</code>: The modifier that is run when the API method is called, of SimulatorModifier type<br />
<br />
<code>SimulatorModifer</code> is called with two deconstructed object parameters:<br />
# <code>args: any[]</code>: Array of arguments passed in the Python code to the method, converted to equivalent JS types.<br />
# <code>prevReturnValue: any</code>: The return value this method would return if the prevReturnValue is undefined.<br />
Multiple plugins can each attach multiple modifiers to a method, all these modifiers will be called in the same order they were<br />
attached.<br />
<br />
The return value of the previous modifier will be passed to <code>prevReturnValue</code>.<br />
<br />
==Widgets Config==<br />
The widgets config is a JSON array of <code>GridItem</code> objects specified in the code tab of the prototype.<br />
<br />
GridItem has 3 properties:<br />
# <code>boxes: number[]</code>: The boxes this grid item should occupy. Boxes must be adjacent (horizontally or vertically) and for<br />
now, a grid item can occupy a maximum of 2 boxes.<br />
# <code>plugin: string</code>: The name of the plugin for this widget. This is the plugin name specified when creating a plugin.<br />
# <code>widget: string</code>: The widget name. This is specified in the plugin code when registering a widget<br />
<br />
= Summary =<br />
The following provides an overview of all elements involved: A vehicle model in the playground includes one instance of a VSS catalogue (e.g. the YAML definition file with all the VSS definitions), n number of plugin implementations, and n number of SdV prototypes. <br />
<br />
The VSS catalogue can be extended to use VSS Wishlist items, defined ad-hoc by different prototypes. digital.auto and COVESA are currently working on a way to submit items from the VSS Wishlist to the COVESA process for standardization of VSS.<br />
<br />
Plugins are defining simulators and widgets. Widgets are providing the UX for simulators (defined in the same of other plugins). In the future, each plugin will be associated with one SdV prototype for documentation purposes, as well as for defining the VSS wishlist APIs which might be required by the plugin.<br />
<br />
SdV prototypes are using plugins. In order to use a plugin, the configuration will have to state where exactly the required widgets should be played on the prototype-specific version of the playground grid.<br />
<br />
[[File:All Playground Elements.png|800px|frameless|center|All Playground Elements]]</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7743Playground Backlog2022-11-18T15:44:01Z<p>Admin: /* BCW feedback / new tasks */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car => Louis<br />
* Merge BEG Vehicle + BEG Vehicle 2 => OK<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading => Chris<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop => Chris<br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs => Chris<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck => Devesh<br />
|-<br />
| Passenger Welcome || 1: Images are flickering => Louis; 2: Remove "Passenger Welcome" model => Devesh<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec => Devesh<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec => Devesh<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins) => Dirk<br />
** Add "Widgets" link to MAIN MENU ("="), pointing to cleaned up version of https://playground-plugins.netlify.app/ => Louis<br />
<br />
UX<br />
* Redundant "play" functions<br />
** Rename tab => "Dashboard" / different icon => Louis<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields (TBD: discuss additional VSS API meta data)<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7742Playground Backlog2022-11-18T15:41:46Z<p>Admin: /* BCW feedback / new tasks */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car => Louis<br />
* Merge BEG Vehicle + BEG Vehicle 2 => OK<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading => Chris<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop => Chris<br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs => Chris<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck => Devesh<br />
|-<br />
| Passenger Welcome || 1: Images are flickering => Louis; 2: Remove "Passenger Welcome" model => Devesh<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec => Devesh<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec => Devesh<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins) => Dirk<br />
** Add "Widgets" link to MAIN MENU ("="), pointing to cleaned up version of https://playground-plugins.netlify.app/ => Louis<br />
<br />
UX<br />
* Redundant "play" functions<br />
** Rename tab => "Dashboard" / different icon => Louis<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7741Playground Backlog2022-11-18T15:40:20Z<p>Admin: /* BCW feedback / new tasks */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car => Louis<br />
* Merge BEG Vehicle + BEG Vehicle 2 => OK<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading => Chris<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop => Chris<br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs => Chris<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck => Devesh<br />
|-<br />
| Passenger Welcome || 1: Images are flickering => Louis; 2: Remove "Passenger Welcome" model => Devesh<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec => Devesh<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec => Devesh<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins) => Dirk<br />
** Add "Widgets" link to MAIN MENU ("="), pointing to cleaned up version of https://playground-plugins.netlify.app/ => Louis<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7740Playground Backlog2022-11-18T15:25:42Z<p>Admin: /* BCW feedback / new tasks */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car => Louis<br />
* Merge BEG Vehicle + BEG Vehicle 2 => OK<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading => Chris<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop => Chris<br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs => Chris<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck => Devesh<br />
|-<br />
| Passenger Welcome || 1: Images are flickering => Louis; 2: Remove "Passenger Welcome" model => Devesh<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec => Devesh<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec => Devesh<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins)<br />
** Incorporate re-usable JS library into playground + documentation (in addition to widgets / prototypes)<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7739Playground Backlog2022-11-18T15:22:09Z<p>Admin: /* Use Cases */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car => Louis<br />
* Merge BEG Vehicle + BEG Vehicle 2 => OK<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading => Chris<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop => Chris<br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs => Chris<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck => Devesh<br />
|-<br />
| Passenger Welcome || 1: Images are flickering => Louis; 2: Remove "Passenger Welcome" model => Devesh<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec => Devesh<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec => Devesh<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Requirements management<br />
* How / where do we want to manage requirements / tasks in the future: GitHub, Wiki, Google Chat, ...?<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins)<br />
** Incorporate re-usable JS library into playground + documentation (in addition to widgets / prototypes)<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7738Playground Backlog2022-11-18T15:20:23Z<p>Admin: /* Use Cases */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car => Louis<br />
* Merge BEG Vehicle + BEG Vehicle 2 => OK<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading => Chris<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop => Chris<br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs => Chris<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck => Devesh<br />
|-<br />
| Passenger Welcome || 1: Images are flickering => Louis; 2: Remove "Passenger Welcome" model => Devesh<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Requirements management<br />
* How / where do we want to manage requirements / tasks in the future: GitHub, Wiki, Google Chat, ...?<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins)<br />
** Incorporate re-usable JS library into playground + documentation (in addition to widgets / prototypes)<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7737Playground Backlog2022-11-18T15:00:30Z<p>Admin: /* Use Cases */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car => Louis<br />
* Merge BEG Vehicle + BEG Vehicle 2 => OK<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading => Chris<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop <br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck<br />
|-<br />
| Passenger Welcome || 1: Images are flickering; 2: could this be moved to ACME EV model?<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Requirements management<br />
* How / where do we want to manage requirements / tasks in the future: GitHub, Wiki, Google Chat, ...?<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins)<br />
** Incorporate re-usable JS library into playground + documentation (in addition to widgets / prototypes)<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7736Playground Backlog2022-11-18T14:58:46Z<p>Admin: /* Use Cases */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car => Louis<br />
* Merge BEG Vehicle + BEG Vehicle 2 => OK<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop <br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck<br />
|-<br />
| Passenger Welcome || 1: Images are flickering; 2: could this be moved to ACME EV model?<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Requirements management<br />
* How / where do we want to manage requirements / tasks in the future: GitHub, Wiki, Google Chat, ...?<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins)<br />
** Incorporate re-usable JS library into playground + documentation (in addition to widgets / prototypes)<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7735Playground Backlog2022-11-18T14:57:38Z<p>Admin: /* Use Cases */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck => Louis<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car<br />
* Merge BEG Vehicle + BEG Vehicle 2<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop <br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck<br />
|-<br />
| Passenger Welcome || 1: Images are flickering; 2: could this be moved to ACME EV model?<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Requirements management<br />
* How / where do we want to manage requirements / tasks in the future: GitHub, Wiki, Google Chat, ...?<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins)<br />
** Incorporate re-usable JS library into playground + documentation (in addition to widgets / prototypes)<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7734Playground Backlog2022-11-17T11:55:12Z<p>Admin: /* BCW feedback / new tasks */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car<br />
* Merge BEG Vehicle + BEG Vehicle 2<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop <br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck<br />
|-<br />
| Passenger Welcome || 1: Images are flickering; 2: could this be moved to ACME EV model?<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Requirements management<br />
* How / where do we want to manage requirements / tasks in the future: GitHub, Wiki, Google Chat, ...?<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins)<br />
** Incorporate re-usable JS library into playground + documentation (in addition to widgets / prototypes)<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
* Eclipse<br />
** Select org<br />
** Pass VSS file + link to documentation<br />
** Visibility of repo: Public or Private?<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7733Playground Backlog2022-11-16T16:23:02Z<p>Admin: </p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car<br />
* Merge BEG Vehicle + BEG Vehicle 2<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop <br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck<br />
|-<br />
| Passenger Welcome || 1: Images are flickering; 2: could this be moved to ACME EV model?<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec<br />
|}<br />
<br />
CES<br />
* [https://wiki.covesa.global/display/WIK4/EV+Optimization+-+Increase+Travel+Range+for+Fixed+Battery EV Optimization]<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Requirements management<br />
* How / where do we want to manage requirements / tasks in the future: GitHub, Wiki, Google Chat, ...?<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins)<br />
** Incorporate re-usable JS library into playground + documentation (in addition to widgets / prototypes)<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7732Playground Backlog2022-11-16T14:18:47Z<p>Admin: /* BCW feedback / new tasks */</p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car<br />
* Merge BEG Vehicle + BEG Vehicle 2<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop <br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck<br />
|-<br />
| Passenger Welcome || 1: Images are flickering; 2: could this be moved to ACME EV model?<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec<br />
|}<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Requirements management<br />
* How / where do we want to manage requirements / tasks in the future: GitHub, Wiki, Google Chat, ...?<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins)<br />
** Incorporate re-usable JS library into playground + documentation (in addition to widgets / prototypes)<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
* Plugins<br />
** Library + documentation<br />
** Themes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7731Playground Backlog2022-11-16T13:56:27Z<p>Admin: </p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car<br />
* Merge BEG Vehicle + BEG Vehicle 2<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop <br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck<br />
|-<br />
| Passenger Welcome || 1: Images are flickering; 2: could this be moved to ACME EV model?<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec<br />
|}<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Requirements management<br />
* How / where do we want to manage requirements / tasks in the future: GitHub, Wiki, Google Chat, ...?<br />
<br />
Tags<br />
* Add tags according to spec<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins)<br />
** Incorporate re-usable JS library into playground + documentation (in addition to widgets / prototypes)<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
* Fix "TBDs"<br />
** Search/filters<br />
** Auto-insert code for APIs<br />
** Editing of all text fields<br />
** Link between plugins/prototypes<br />
<br />
APIs<br />
* Import / export<br />
* Wishlist => COVESA<br />
<br />
Deployment<br />
* Make deployment targets (EPAM, Eclipse) pluggable<br />
* Clean up Pyhton code to be closer to deployment target, e.g. (re-)move "await", etc.<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
* 3DS: Make API browser available (instead of iFrame)<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=Playground_Backlog&diff=7730Playground Backlog2022-11-16T13:39:17Z<p>Admin: </p>
<hr />
<div>= Use Cases =<br />
<br />
Public models:<br />
* Merge Truck, Smart Truck, ACME Truck<br />
* Consider removing / merging Rental Car, ACME Car, Test Vehicle N, Testig Passenger Welcome, Demo Car, Test Vehicle M, EL Car<br />
* Merge BEG Vehicle + BEG Vehicle 2<br />
<br />
{| class="wikitable"<br />
|-<br />
! Use Case!! Comments<br />
|-<br />
| ACME EV: Smart Wipers || Wiper animation should display "loading..." while loading<br />
|-<br />
| ACME EV: Smart Wipers / AI || Big Loop <br />
|-<br />
| ACME EV: Motion Sickness / Anti-Kinetosis || Make main algorithm visible in prototype; ensure proper use of VSS APIs<br />
|-<br />
| ACME EV: Basic Monitoring|| Remove from ACME EV, move to Smart Truck<br />
|-<br />
| Passenger Welcome || 1: Images are flickering; 2: could this be moved to ACME EV model?<br />
|-<br />
| Mahindra || Review proper use of VSS APIs<br />
|-<br />
| City Transformer || Review proper use of VSS APIs<br />
|-<br />
| Smart Trailer || Finalize demo according to CVO spec<br />
|-<br />
| Smart Truck || Finalize demo according to CVO spec<br />
|}<br />
<br />
= BCW feedback / new tasks=<br />
<br />
Requirements management<br />
* How / where do we want to manage requirements / tasks in the future: GitHub, Wiki, Google Chat, ...?<br />
<br />
Plugin Library<br />
* VSS pill: accept "label" to overwrite VSS signal name<br />
* VSS table: Cut off name on the left, not on the right ("...Front.Wiping.Mode")<br />
* General<br />
** Clean up documentation ("plugin howto", but also documentation for individual plugins)<br />
** Incorporate re-usable JS library into playground + documentation (in addition to widgets / prototypes)<br />
<br />
UX<br />
* Redundant "play" functions: tab name, control panel, custom ">" buttons<br />
** Rename tab?<br />
** Make ">" a plugin? (also for stop, forward, re-start)<br />
<br />
Deployment<br />
<br />
Customer Journey Analysis / EAM<br />
* Review<br />
* Ownership => Jens?<br />
<br />
Misc<br />
* SdV 101 / wiki: fix alignment of tooltip messages for image areas<br />
<br />
<br />
=Short Term (old)=<br />
<br />
MediaWiki<br />
* Current newsletter form only asks for AIoT - include registration for digital.auto-specific newsletter<br />
<br />
Customer Journey<br />
* The top of the Edit button for a CJ is 100% aligned with the top of the CJ table rendering. Maybe move the button up or down a bit, would look better.<br />
<br />
PINs<br />
* Tooltip for pin at the very top not visible<br />
* When selecting pin in an image, the VSS details are shown on the right side only; on the left side (VSS list), the VSS API should also be selected and highlighted<br />
<br />
Media Library<br />
* When associating an image from the library with an item like a prototype, it usually says "Upload image". In fact, to upload I have to go to the media library. So in the menu it should say "Attach image", and maybe include a link to the media library (open in new tab) so I can upload a new image if need be.<br />
<br />
Prototype/User Feedback<br />
* Still need to add "edit" functionality for "Feedback"<br />
<br />
Landing page (after selecting model)<br />
* "CVI Catalogue" => "Interface Catalogue (CVI)" (above "Browse, enhance, and ...")<br />
<br />
Python Mappings<br />
* Add "set_testdata()" functions<br />
<br />
VSS List<br />
* Would be good if I can select and copy the name of a VSS API ("vehicle.body...") in the API details view on the right side of the API list<br />
<br />
Media Library<br />
* Allow uploading of new versions of images, replacing existing ones<br />
<br />
User Accounts<br />
* Add image, real name (optional)<br />
<br />
=Medium Term=<br />
<br />
Key Epics (needed for BCW)<br />
* [[Playground_Plug-Ins|Plug-Ins]]<br />
** Provide a well structured and well documented "Google Maps"-type of reference implementation of a plug-in, which can be used for example in Smart Wipers<br />
* [[Playground_Analysis|Analysis]]<br />
* [[Playground_Access_Control|Access Control]]<br />
* [[Playground_Tags|Tags]]<br />
<br />
Eclipse<br />
* Velocitas Python mapping compliance<br />
* Contribution of VSS browser to Velocitas (de-coupled from media library and other potential dependencies)<br />
<br />
Prototype/Code<br />
* Add list of used APIs + wishlist for this prototype<br />
* Support "add sample code"-button<br />
* Automatically update "APIs used" list after each successful "run"<br />
<br />
CVI Catalogue<br />
- Add filter "Show all" | "VSS Standard" | "Wishlist"<br />
- Add dedicated "Wishlist" page, including process for requesting new VSS APIs added to official catalogue (input from Erik)<br />
- Up-/Down-voting for wishlist-entries<br />
<br />
Playground Markup<br />
* In addition to {{}}, we should also consider supporting bullet poins like in media wiki (for CJ definitions, EA components, user feedback, etc.)<br />
<br />
Logging<br />
* Add trace / change log which records of all changes / edits, including time stamp and user ID<br />
<br />
=Long Term=<br />
* Social Media Integration / LinkedIn<br />
<br />
=DONE=<br />
* Move done tasks here</div>Adminhttps://www.digitalplaybook.org/index.php?title=SdV101_Build,_Measure,_Learn_%E2%80%93_Repeat&diff=7725SdV101 Build, Measure, Learn – Repeat2022-11-09T09:03:41Z<p>Admin: </p>
<hr />
<div>__NOTOC__<br />
<imagemap><br />
File:SdV101 Banner BMLR.png|2000px|frameless|center|digital.auto<br />
rect 41 214 211 271 [[SdV_101|SdV 101]]<br />
rect 1831 24 1901 70 [[SdV101_Introduction|Introduction]]<br />
rect 1834 79 1903 122 [[SdV101_Value_Stream_Management|Value Stream Management]]<br />
rect 1831 132 1903 178 [[SdV101_Enabling_Technologies|Enablin Technologies]]<br />
rect 1831 187 1903 235 [[SdV101_Digital_First-Exploration|„Digital First“-Exploration]]<br />
rect 1834 240 1903 286 [[SdV101_Enterprise_Architecture_and_Organization|Enterprise Architecture & Organization]]<br />
rect 1836 298 1903 341 [[SdV101_Build,_Measure,_Learn_–_Repeat|Build, Measure, Learn – Repeat]]<br />
desc none<br />
</imagemap><br />
<br />
<s data-category="DigitalAuto"></s><br />
This module builds on the modules before and brings all elements together to help OEMs realize a "build, measure, learn - repeat" cycle, including a discussion on crowd testing for the SdV.<br />
__TOC__<br />
<br />
=Mapping to SdV 101 Framework=<br />
The following figure is mapping this module to the SdV 101 Framework.<br />
<imagemap><br />
File:SdV101 BMLR Map.png|800px|frameless|center|SdV101 Framework<br />
<br />
rect 682 557 1831 958 [[SdV101_Value_Stream_Management|01 Value Stream Management]]<br />
rect 106 554 569 965 [[SdV101_Enabling_Technologies|02 Enabling Technologies]]<br />
rect 98 58 1154 298 [[SdV101_Digital_First-Exploration|03 "Digital First"-Exploration]]<br />
rect 682 312 1250 540 [[SdV101_Enterprise_Architecture_and_Organization|04 Enterprise Architecture & Organization]]<br />
<br />
desc none<br />
</imagemap><br />
<br />
=SdV and the "build, measure, learn - repeat" cycle=<br />
This lesson provides an overview of how SdV and the "build, measure, learn - repeat" cycle fit together.<br />
<imagemap><br />
File:SdV101 BMLR.png|600px|frameless|center|empty<br />
circle 196 895 105 [https://drive.google.com/file/d/1Cv4cIXn5-zS9Hfox-b9MUvXldS4ZBJyF/view?usp=share_link PLAY VIDEO]<br />
desc none<br />
</imagemap></div>Adminhttps://www.digitalplaybook.org/index.php?title=SdV101_Build,_Measure,_Learn_%E2%80%93_Repeat&diff=7724SdV101 Build, Measure, Learn – Repeat2022-11-09T09:03:20Z<p>Admin: /* SdV and the "build, measure, learn - repeat" cycle */</p>
<hr />
<div>__NOTOC__<br />
<imagemap><br />
File:SdV101 Banner BMLR.png|2000px|frameless|center|digital.auto<br />
rect 41 214 211 271 [[SdV_101|SdV 101]]<br />
rect 1831 24 1901 70 [[SdV101_Introduction|Introduction]]<br />
rect 1834 79 1903 122 [[SdV101_Value_Stream_Management|Value Stream Management]]<br />
rect 1831 132 1903 178 [[SdV101_Enabling_Technologies|Enablin Technologies]]<br />
rect 1831 187 1903 235 [[SdV101_Digital_First-Exploration|„Digital First“-Exploration]]<br />
rect 1834 240 1903 286 [[SdV101_Enterprise_Architecture_and_Organization|Enterprise Architecture & Organization]]<br />
rect 1836 298 1903 341 [[SdV101_Build,_Measure,_Learn_–_Repeat|Build, Measure, Learn – Repeat]]<br />
desc none<br />
</imagemap><br />
<br />
<s data-category="DigitalAuto"></s><br />
This module builds on the modules before and brings all elements together to help OEMs realize a "build, measure, learn - repeat" cycle, including a discussion on crowd testing for the SdV.<br />
__TOC__<br />
<br />
=Mapping to SdV 101 Framework=<br />
The following figure is mapping this module to the SdV 101 Framework.<br />
<imagemap><br />
File:SdV101 BMLR Map.png|800px|frameless|center|SdV101 Framework<br />
<br />
rect 682 557 1831 958 [[SdV101_Value_Stream_Management|01 Value Stream Management]]<br />
rect 106 554 569 965 [[SdV101_Enabling_Technologies|02 Enabling Technologies]]<br />
rect 98 58 1154 298 [[SdV101_Digital_First-Exploration|03 "Digital First"-Exploration]]<br />
rect 682 312 1250 540 [[SdV101_Enterprise_Architecture_and_Organization|04 Enterprise Architecture & Organization]]<br />
<br />
desc none<br />
</imagemap><br />
<br />
=SdV and the "build, measure, learn - repeat" cycle=<br />
This lesson provides an overview of how SdV and the "build, measure, learn - repeat" cycle fit together.<br />
<imagemap><br />
File:SdV101 BMLR.png|600px|frameless|center|empty<br />
circle 196 895 105 [https://drive.google.com/file/d/1Cv4cIXn5-zS9Hfox-b9MUvXldS4ZBJyF/view?usp=share_link PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Crowd Testing=</div>Adminhttps://www.digitalplaybook.org/index.php?title=SdV101_Enterprise_Architecture_and_Organization&diff=7723SdV101 Enterprise Architecture and Organization2022-11-09T09:02:25Z<p>Admin: /* Enterprise Perspective */</p>
<hr />
<div>__NOTOC__<br />
<imagemap><br />
File:SdV101 Banner EAM.png|2000px|frameless|center|digital.auto<br />
rect 41 214 211 271 [[SdV_101|SdV 101]]<br />
rect 1831 24 1901 70 [[SdV101_Introduction|Introduction]]<br />
rect 1834 79 1903 122 [[SdV101_Value_Stream_Management|Value Stream Management]]<br />
rect 1831 132 1903 178 [[SdV101_Enabling_Technologies|Enablin Technologies]]<br />
rect 1831 187 1903 235 [[SdV101_Digital_First-Exploration|„Digital First“-Exploration]]<br />
rect 1834 240 1903 286 [[SdV101_Enterprise_Architecture_and_Organization|Enterprise Architecture & Organization]]<br />
rect 1836 298 1903 341 [[SdV101_Build,_Measure,_Learn_–_Repeat|Build, Measure, Learn – Repeat]]<br />
desc none<br />
</imagemap><br />
<s data-category="DigitalAuto"></s><br />
This module introduces an enterprise SdV target architecture, with a focus on managing the distributed and heterogeneous elements of modern vehicle applications and data-driven mobility solutions. Provides a discussion on the digital operations aspects.<br />
__TOC__<br />
<br />
=Mapping to SdV 101 Framework=<br />
The following figure is mapping this module to the SdV 101 Framework.<br />
<br />
<imagemap><br />
File:SdV101 Fwk EA.png|800px|frameless|center|SdV101 Framework<br />
<br />
rect 682 557 1831 958 [[SdV101_Value_Stream_Management|01 Value Stream Management]]<br />
rect 106 554 569 965 [[SdV101_Enabling_Technologies|02 Enabling Technologies]]<br />
rect 98 58 1154 298 [[SdV101_Digital_First-Exploration|03 "Digital First"-Exploration]]<br />
rect 1270 53 1829 542 [[SdV101_Build,_Measure,_Learn_–_Repeat|05 Build, measure, learn - repeat]]<br />
<br />
desc none<br />
</imagemap><br />
<br />
=SdV Target Architecture=<br />
This lesson provides an overview of an - potentially slightly idealized - SdV target architecture, which can be used to look at architecture holistically, and from a software-first perspective. <br />
<imagemap><br />
File:SdV101 EAM Intro.png|600px|frameless|center|empty<br />
circle 196 895 105 [https://drive.google.com/file/d/1CzUhrFshqSrd0aA4rSbGLgkLBL0_Qhav/view?usp=share_link PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Example: Weather Warning=<br />
This lesson is applying the SdV target architecture to an example: A weather warning app is discussed in detail.<br />
<br />
<imagemap><br />
File:SdV101 EA Example Weather.png|600px|frameless|center|empty<br />
circle 196 895 105 [https://drive.google.com/file/d/1zVQsriRsNxrYdJqs-h8MHIbDW4y2hyLM/view?usp=share_link PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=How to Organize the Work?=<br />
This lesson is looking at the relationship between architecture and organization, and how to best organize the work in the context of the architecture decisions which are made.<br />
<imagemap><br />
File:SdV101 EA Work.png|600px|frameless|center|empty<br />
circle 196 895 105 [https://drive.google.com/file/d/1xzKUCmcYABD7d9pLzr02_BMWSgYFiWkw/view?usp=share_link PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=How to get there?=<br />
The big question now is, how to get to the SdV target architecture: Top down or bottom up? This lesson is discussion the pros and cons. <br />
<imagemap><br />
File:SdV101 How.png|600px|frameless|center|empty<br />
circle 196 895 105 [https://drive.google.com/file/d/1Q7WdSFU5zYQdLG0WxQOwRymt7tFqXeAn/view?usp=share_link PLAY VIDEO]<br />
desc none<br />
</imagemap><br />
<br />
=Enterprise Perspective=<br />
Finally, we must look at the end-to-end enterprise perspective, as most OEMs with multiple brands and multiple platforms are taking it.<br />
<imagemap><br />
File:SdV101 EA Enterprise.png|600px|frameless|center|empty<br />
circle 196 895 105 [https://drive.google.com/file/d/1yWs0kWaQCwkthH6eum6b54-5xEvIFxl9/view?usp=share_link PLAY VIDEO]<br />
desc none<br />
</imagemap></div>Admin