Project Meeting, Thursday 5 September, 2019, 5pm CET
Project Meeting, Thursday 22 August, 2019, 5pm CET
Project Meeting, Thursday 8 August, 2019, 5pm CET - WATCH OUT this is a project restart
Concerning the DLT demo, I would recommend that you look first at the following materials which are available on the public GENIVI wiki (please look at them in the following order) and even try out DLT as explained in  below
Project Meeting, Wednesday April 25, 2018, 0900 CET
BMW dlt viewer maintainer
BMW dlt Alex Wenzel former dlt maintainer
BMW Car-IT x 4
Mobis X 2
Nishio-san, Alpine, GENIVI UML model maintainer
+ Some more participants from Korea (if you were there, please write your name)
3/4 room full
half the attendees do not know about the project
Intro (Gunnar) - see slide deck
- debugging (during development)
- system health (when product is deployed): e.g. watchdog
- logging (during development and sometimes in deployed products)
- tracing (during development and sometimes in deployed products)
BMWCarit agrees with the use cases
Slide from DIRO report shown on Tuesday about managing integration complexity
added in the scope: security threat evaluation / mitigation
not primarily looking at these aspects though
Slide from DIRO report shown on Tuesday about the development being too long (gpro <-> shda)
Review of presentations performed in Q1, 2018
look at https://at.projects.genivi.org/wiki/display/DIRO/SHDA+meeting+minutes - Technologies to investigate
Guider:lightweight tool, text based
CDL: data gathering
Dlt, multinode DLT
Polling the audience about tool usage
BMW: mainly using DLT for debugging, sometimes we add dlt viewer plugins
For performance analysis we use other tools like systemtap, kernel tracing
Elektrobit/Torsten: interested in knowing how the hypervisor is working and how the Linux is working, for instance one cannot see a virtual device form outside
DLT will not help for real performance problems.
Talked to QNX and GHS about the analysis of performance problems and asked them to provide different solutions to meet our needs
Profiling data would help, there are some standard formats,
is there an interest in profiling data using a standard approach ?
It is necessary to do it. I often
we need to correlate data, what is the correlated data timebase ?
Someone mentioned Ethernet AVB (for time sync)
TSN / AVB could be used for timing sync sometimes, but we need a more generic solution
BMW Car IT
Understanding a distributed system does not require a so detailed time analysis
you have rather to understand the sequence / logical set of events
we need to understand the abstracted behaviors
IMHO this is not possible using one single tool
is there work to do to unify data format for a more abstract tracing.
(i.e. "events" and "messages", etc. -- this was following onto the idea of
low level tooling such as kernel trace tools, which has a bit of standards in
Linux for tracing data format)
currently I have to transform format in order to perform the analysis.
(Torsten writes his own tools and data transformations whenever needed)
Operating systems should not be able to log other operating system resources (?)
How bad are ascii textfiles above more structured data ? We prefer using grep
DLT is not so much in advance of that, but is much better that text/grep
(Gunnar: I'm wondering about more structured data formats for automate processing. Agree there is *some* structure to DLT - at least each component has its own code, and each message is time stamped -- implying that the source (on component level) is one thing you can filter on, and of course log level).
I am still text based and use emacs for search
you need a database, the text format is not sufficient
you need both. I dump my data into a database also. Doing SQL queries can be useful.
I could release why I am doing in the open source because this is personal work, not sponsored by EB, however I use this tooling for debugging things at EB
DLT seems to deserve some investigation
comment from a participant refering to an commercial opportunity for new tools
DLT with additional multinode is a good tool
Tools to understand the high level interaction are also good
We target both HV and distributed systems
BMWCarit: I am interested in assessing the system stability,
(but also improve how to build stable systems -- my work includes not only technology, also things all the way up to development process)
Gunnar:the whole development process is perhaps a little too wide scope for this project, but the technology is interesting.
• System Health
Automated monitoring and remedy of problems, wrongful behavior and warning signs during normal operation (product is deployed)
Finding and fixing software defects, once the effect of the defect has been noticed. (During product development).
Reporting of internal state using potentially free form, for the purpose of understanding the system (development, sometimes in deployed product)
Structured and detailed logging of internal system state, such that it enables automated processing (development, sometimes deployed)
EB solys is more a framework, it provides the tooling for analyzing different kinds of data, it is event-based, every data item is time stamped, it provides a means to correlate the data across several data channels
target agent was used on QNX, Android, Windows CE, Windows Embedded
the target agent code for Android is different
we use poco framework and google protobuf, it is implemented in cpp11
unlimited usage of downloadable sw
30 days of pro features which are the scripting capabilities
mobica: useful base, needs customization
ivis: feature wise it is good, how to connect this tool to the autosar domain ? both CP & AP (Classic Platform, Adaptive Platform)
EB: if you use DLT as the tracing & logging framework in CP, DLT files can be imported into solys
EB: for AP, if it is a linux-based implementation, all the features shown apply
connection to Franca IDL
Torsten would be the right contact
look at itemis blog site for some information
solys agent code: https://github.com/Elecktrobit/eb-solys-target-agent
the objective of the call is to followup on actions after last week's initial call and to agree on presentations for the next weeks
Roundtable presentations (missed 1-2 who joined later)
Intro to Domain-interaction and this project by Gunnar
Review of scope & definitions
Birk: BMW would not limit the Debug to product development, e.g. core dumps from the field are useful and can be debugged
Gunnar: OK, let's change it to "mainly" during development
Marc : Agree with the definitions
Comments on system health.
Went through project goal ideas.
Gunnar: Asking for project lead volunteer.
Marc: The project sounds interesting, but need to check with colleagues/management for the scope of engagement
Gunnar: Yes I expect most everyone needs to do that now that you have a feel for the project purpose
Which technologies should we study?
BMW: points out all data loggers we are using at BMW rely on DLT - [i.e. commercial vendors support this also]
Daniel - intel: when will this project come to life ? Time plan, deliverables, for example what has been reached at end of this year?
Gunnar: All the way to end of year I'd personally like to see most of the goals met, and maybe the project being "done". (We should work towards achieving results in reasonable time) This is the interest/scoping meeting however, so it's impossible to make firm predictions before knowing who will get heavily involved to produce the results. It is really up to all of you as project participants!