| Automotive Task Group Minutes | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Task Group Meeting - Paris, 3rd April 2002 [pdf download] Task Group Project Meeting - Paris, 10th December 2002 [pdf download] Task Group Project Meeting - Munich, 3rd February 2003 [pdf download] Task Group Project Meeting - Esslingen-a-N, 21st March 2003 [pdf download] Task Group Project Meeting - Herrsching, 13th February 2004 [pdf download]
MONET Automotive Task Group Meeting - Paris, 3rd April 2002
Present:
Agenda Activities of
the Task Group Any Other Business Task Group Activities 1. Dissemination Materials It was agreed that Dissemination Materials needed to be produced and then sent to targeted individuals and companies as well as to magazines and periodicals within the Automotive Industry, with examples of the current technologies. It was agreed that some of these materials should be in the form of Management Overviews, with links to relevant contacts and papers for those in the field. Suggestions as to types of materials to be used included - Demo
versions of Systems for public/industrialists to try - Autosteve
and On Board Diagnosis. (Apparently this was intended for MONET1
but ran into problems such as what platforms to use.) There was some discussion on how and where do the Tutorials - live at various conferences and workshops? Should it be available on-line as interactive software? Also on what would be used and who would produce the material. Peter Struss and Neal both have tutorials that could be used either as whole or part of new tutorials. It was agreed that Neal, Janet and possibly Chris Price would tie together all the available tutorial materials. They would try to complete this task in time for DX meeting in May. There is also the possibility of using these tutorials at other related events, such as the MONET Summer School, the BDI Conference, Baden Baden in September 2003, The ATA Workshop at San Serif (Fulvio to check the dates and details) and Convergence 2002 in France. Activities to demonstrate what the dissemination materials can do were also discussed. It was agreed that research would be required on how to introduce and train for technology integration - following up from IDD. 2. Preparation of Roadmap for next year It was agreed that this should include information on topics of interest to industry. In view of the ensuing discussion on topics for FP6, it was decided to await the return of the questionnaires being produced for this. 3. Framework 6 Topics There has been a call for Expressions of Interest relating to the FP6 funding. The EoI asks for research topics likely to be of interest to the European Community in general. All present read through the relevant paperwork and it was decided that a questionnaire will be produced and sent to various individuals within the Automotive Industry who have expressed an interest in being involved. The questionnaire will identify and focus industrial problems that can be addressed by MBS. It will also aim to promote standards to suppliers. Various problems
are being considered at present including; (UWA are also hoping to feed this work into First Earth along with the softFMEA project which is ongoing and has two years to run. Additional work is being done on Modeling Protocols using SDL etc.) Everyone discussed whether it would be better to have one general EoI or several very specific ones. No real outcome was achieved. The questionnaire and supporting documents are to be prepared by Luca Console and Fulvio Cascio by 15/4/02. They will also contact EUCAR to see what assistance and advice is available. The questionnaire will give specific problem examples and then state what MBS are available and what they can do, then ask what their company uses, how it could be improved, what problems there are, what is useful and what is needed. Specific questions would be included regarding design process and what problems there are. Supporting documentation
will include The questionnaire will then be distributed to the various contacts in industry by 20/4/02 and the companies will be given a return deadline of beginning of May. The results will be analysed and discussed by all Task Group Members who attend DX meeting in Vienna. The findings will be incorporated and sent as part of the Expression of Interest to the Commission by 7/6/02. Further discussion involved whether outside input should be included and if so from whom and how to get specific feedback to identify industrial problems. Organisations that would definitely be contacted are Ford Jaguar Daimler Chrysler
Various other
topics were suggested as being relevant to the EoI proposal, including Any Other Business a. Luca and Peter would decide whether a meeting was necessary to discuss and progress the FP6 Expression of Interest. 28th May was pencilled in as a potential date for this if any outstanding issues had not been resolved by email. They would contact any other TG members who needed to attend or have input accordingly. b. Members wanted to know what the limitations were on their budget usage. Janet agreed to get information and feed this back with the minutes. c. How to recruit and involve new members from the Automotive Industry (including suppliers) was discussed. It was agreed that Members would notify Janet with new contact details and she would send out New Member information packs to them. d. Details of
next meeting to be discussed and finalised at DX Meeting in Vienna
in May, and notified to MONET Admin for travel arrangements to be
made at an appropriate time.
MONET Automotive Task Group Meeting - Paris, 10th December 2002 Integrated Project Proposal Attendance List
Introduction
- Luca Console Round Table
Introduction of Participants and Interest Area's FirstEarth
- Modelling for design analysis Introduction
to the MONET Network - Iain Russell Presentations [Action - Participants to send their presentations to Iain for distribution] Reinhard
Schieber - Audi (Presentation
slides - pdf) Project Proposal - Analyse tools for project testing, generate prototype and introduce to Industry. Q. Can one model
be enough? Q. Would this
model concatenate all layers of development, communication, function,
etc? Q. Will you
use the model for automatic generation of test inputs? Q. Do you need
a more complex model for testing? Q. Is this a
qualitative model? Q. OK or Fault
model? Q. Is the model
used, the one that forms the specification?
Main goals are in preventive diagnosis and fault prevention. Could be in design phase (reliability, fault tolerance), onboard (early warning, risk analysis) or after sales (statistical analysis, fault information, risk analysis, support for preventive maintenance). Q. How do you
intend to achieve an onboard early warning system? Q. Do you want
to get indication of systems that are at risk, i.e. indication that
a component will be ok but will need replacing during the next maintenance? Q. Do you need
empirical data? Q. Do you have
access to it? Luca Console
- Universite del Torino IDD - Continuation of VMBD. VMBD showed that onboard diagnosis did not prove easy mainly due to number and location of available sensors - sensors were there for monitoring and not diagnosis. IDD has the goal of bringing diagnosis forward in the lifecycle to control the design process. It studied current design processes and identified where diagnosis issues are taken into account. The aim was to design tools to be used by designer to aid in the design process. The project has built these tools; these could then be given design and sensor placement. The project tools could then indicate what can be diagnosed and what can be detected with existing sensors, also have design tools to support FMEA and derive onboard diagnosis tools. Q. What aspects
of a qualitative model can be transferred to quantitative? Q. What are
the landmark criteria? Q. If you derive
land marks this way how do you handle double / multi faults? Q. Have you
assessed different approaches to model based diagnosis?
Q. How do you
integrate functional aspects and constraints (behaviour) into you
models? Thyiere Lecomte
- ClearSy (Presentation
slides - pdf) Q. How does
the process go from design specs to B Model? Neil Taylor
- FirstEarth Aim is to reuse the same models for different types of analysis to support the process from design to diagnosis. Q. How do you
work with variant diversity? Soft FMEA - current work has considered CAN buses. Work still to be done is involved with fault mitigation work; using FMEA to show where models could assist fault mitigation strategies. Not FMEA on software but FMEA on some systems that include software. Louise Travé-Massuyés
- CNRS LAAS Q. What does
topological model look like? The second LAAS project is work done within AWAKE. This projects looks at detection of lack of driver attention and also the vehicle and the environment as a whole. The project uses data analysis and learning algorithms. Data is captured from both the vehicle and the environment and then filtered, it then looks at online diagnosis systems as well as off line learning box (details will include information such as the drivers medical records). BRIDGE
MONET EoI
These four topics could form part of proposal or be linked to other topics. ACTIA EoI Basic idea is that three areas are different but good parts could be taken from each. Rose EoI Also BMW The overall vision is to find out how we can take systems and build models over the whole thing - including mechanical. This requires us to look at exterior boundaries and means that diagnostics should be sufficient to deal with these issues and also identify which part or unit needs to be replaced. Existing sensors must be used so the plan is to observe inputs and outputs to different sections. DaimlerChrysler
- Most interested in Preventative Diagnosis. As well as MBD
for the Service bay. How do we go forward, we need to identify commitment from parties. By wire systems may be one possible approach. This may also be an enabler for other systems to be included. Specific technologies will not be in the text of the Call, we will have to state that our technology is the answer to the call. Section 2.1 of the work programme covers many of the areas that we have an interest in, however it does not cover the post sales operation and services. Industrialists were asked to indicate which areas that they had the most interest in. 1. Tools for
knowledge management of technical knowledge via models. 2. On-board
systems. 3. Model-based
Testing. 4. Preventative
Diagnosis Point two is possibly the most challenging, point one will not stand on its own as an Integrated Project, but it feeds into the rest. However, if we go for number two there is the possibility of using some proportion of the funds for point one. In general, the project does not have to be limited to model based technologies, we could look at a comparative business model to investigate which approach is most efficient. Above all there must be (and we must demonstrate) strong business reasons for all that we attempting. Other Partners
Next Steps 1. VW-Audi Two or three pages, possibly the shorter the better and very clear cut. Requirements deadline: Jan 20th. Step 2: Look at Call, study it. Look for further partners. Action - Iain to set up mailing list for this group of people separate to automotive: monet-autoFP6@aber.ac.uk Step 3: Next
meeting should probably be in early February. One possibility is
February 3rd in Munich.
Automotive
Project Meeting
NOTE: Distribute the final minutes and Proposal Texts to all here present and those at the Paris meeting. This needs to go to other potential partners as well (id these with help of others at this meeting) Abbreviations used in this text. IP('s) -
Integrated Project(s). A structure for a medium sized Project
under FP6. MINUTES Welcome from Peter Baude (BMW). Agenda by
Luca Console. 2. Continue
discussion of topics from Paris and identify our interests and how
to move each section forward. 3. How to proceed with project. We need to address issues such as how to turn our ideas into a full Project Proposal and how to structure the Consortium. Calls. There are two Calls which cover the areas in which we are interested; Sustainable Development and also IST. Sustainable
Development (Deadlines of March and October 2003) Objective
1. First Call - New Technologies and Concepts for All Surface
Transport Systems. Objective
2. Second Call - Advanced design and production techniques. Also 2.3 and
2.5 may be relevant at least for the aspects of preventative diagnosis. 4.13 Developing integrated safety systems 4.14 Designing user friendly driver interfaces Call then discusses what actions it wants. CALL 1B - Instruments Objective 1 - Research Domains 2.1 - 2.7 are only looking for CA's. Research Domains 2.5, 2.6, 2.7 are looking for IP's. This is the only research domain that fits our requirements and is applicable to automotive. Research Domains 4.11 - 4.14 are requesting STRePs. IST Calls First Call
(Deadline April 2003) 2.3.1.7 Semantic system and Knowledge based systems. Could be applicable but this is apparently a very popular area of research. The Work Programme
gives the following description of this area; Discussion of Three Main Objectives. Transport
2.1 - 2.2 EUCAR Semantic
Knowledge based systems. The Way Forward One possibility is to aim the Project towards more than one Objective. The Commission had stated that they are more than willing to accept Proposals that address more than one Objective, but they strongly advise that a primary objective is clearly identified. It is important for us to decide what we want to do and then go to the Commission for clarification. The way forward should be to go through the topics and identify what is important and then identify groups within the meeting participants who can address these issues, with the possibility of drafting a proposal today before we begin to talk to the Commission. We should look at a proposal based on what we would do anyway and then design it to fit the call. It is important for us to look at the manufacturing people first and aim the project at increasing manufacturing competitiveness. Look at needs and then service them. Discussion of the Four Research Topic Areas Topics are as
follows ====================================================================== TOPIC 1: Tools for Knowledge management of technical knowledge via models 1) The Problems 2) Industry
Requirements 3) The Foreseen
Solutions 4) Benefits 5) Type of
Project / Potential Consortium (companies) 6) Link to
the Call =================================================================== TOPIC 2: On-board systems; integration of control and diagnosis; software solutions for the deployment of model-based diagnosis on-board. 1) The Problems 2) Industry
Requirements 3) The Foreseen
Solutions 4) Benefits 5) Type of
Project / Potential consortium (companies) 6) Link to
the Call =================================================================== 2) Industry
Requirements 3) The Foreseen
Solutions 4) Benefits 5) Type of
Project / Potential Consortium (companies) 6) Link to
the Call =================================================================== TOPIC 4: Preventive Diagnosis. 1) The Problems 2) Industry
Requirements 3) The Foreseen
Solutions 4) Benefits 5) Type of
Project / Potential Consortium (companies) 6) Link to
the Call =================================================================== LINKS BETWEEN THE 4 TO CREATE A UNIQUE IP A set of solutions and tools for supporting the automotive life cycle towards safer, more reliable, environmentally friendly vehicles. Topic 1 can be regarded as a foundation for at least topics 2 and 3 (and possibly topic 4)
Iain will take the work done today and take it to the European Liaison Officers and European Regional Offices to discuss these ideas with them. Then we shall put together a plan to take to the Commission Desk Officers, also we could mention this to David Callahan. We should also look into attracting more partners (FIAT & Renault, Peugeot-Citroen). We should distribute this and ask them to get back to us.
Automotive
Meeting - DaimlerChrysler, Esslingen-a-N, Attendance List
Introduction of Bernard Baker - Project Manager for DC Agenda 12.45 - Lunch Role of Partners 17.00 General Status Overview - STReP Presentation by Iain Technical Contents - Presentation by Bernd [Slides] Break down of Potential Project Areas - Luca [Slides - Word Doc] ACTIA - Project Breakdown Proposal - Herve (Ligeron SA) Discussion of the Project Structure General Overview on Submission - Bernd (Project proposal Docs A1 - A3) Proposal Guidance Notes (word) (pdf)
MONET
Automotive Meeting Minutes, Herrsching
Agenda - Report on
Commission evaluations for Call 1 and 2 (by Monet Manager) RIR Presented FP6 Update Contents: - Call
3 Call 3 The third IST Call is to be a corrective Call & joined with NMP. 22nd May to 22nd Sept and will mainly include measures to increase the inclusion of the following: - ACC
- Accession Candidate Countries The Call is likely to include adding partners to existing projects, and a stress on instruments sympathetic to these groups (STRePs). The technical content is likely to be an extract from the existing WorkProgramme. WorkProgramme Revision Timetable. February - March
- Full analysis of results and lessons learnt from 1st and 2nd Call Evaluation Main reasons
that proposals failed in the first two calls were; It is important to remember that Evaluators get about one hour to review the proposal so they have to 'skim' though it. Evaluators claim that they know whether a proposal has passed or failed in the first 2 - 5 minutes. Some evaluators claim that during evaluation discussions, many evaluators stated that the research ideas had been 'boring!' 2% failed due to being ineligible. Some failed because Proposers did not click the 'SUBMIT' button after entering all their details through electronic submission. End Users Evaluators are told to look for proposals which address End Users and issues like 'How many potential users are there for your product?' Impact (used
by the WP a lot) means impact to End Users (not technology itself)
and the proposal must focus on this. However the proposal must also
identify 'how' the impact will be realised and evaluators will be
looking for; Evaluators state that they mark down a project that just looks like a big company sharing the workload. If the Company (or even University) could do the work itself then it will not get funded, so remember to stress the 'essential European cooperation' and a good way is to show the requirement for mobilisation of resources across Europe (i.e. Partners). S&T Excellence Proposals need one clearly identifiable objective, with clearly stated time scales. One Evaluator suggested a very good example was "Before the decade is out, we will put an American on the Moon and return him to Earth safely" J. F. Kennedy, May 1961. In other words the objectives and timescales are clearly described in something not much longer than the project title - Remember 'Evaluators claim that they know whether a proposal has passed or failed in the first 2 - 5 minutes.' Proposals often fall down on their description of the State-of-the-Art, this is very important for S&T Excellence. Sometimes this is not included at all, but more often than not proposal writer states what they (and the consortium) are doing. The Commission however wants the State-of-the-Art to be what everyone in the World is doing. Projects that will bring a competitive edge against US and / or Japan are especially favoured. Embedded Systems Was headed by Kostas Glinos (Very clued in) although moving to FET - 111 proposals 23rd March 2004 - Embedded systems - Consultation Workshop. Brussels. Future Strategic Objectives There has not been a confirmation that any SO will be repeated. Some we know will be - Embedded Systems. However, all units within DG 3 were represented in the SO's for Calls 1 & 2 and therefore it seems sensible to assume they will be again. FP6 Discussion There is plenty of time to consider proposals. The draft WorkProgramme (WP) is likely to be out soon, however the formal release is not likely to be until the IST Conference in November 2004. The meeting was reminded, however, that relevance to the WP is the single most important factor in FP6 Project Evaluation and with the Commission currently offering a consultation process on Strategic Objectives (SO's) it is important to become involved. We should attempt to influence the process and work towards the inclusion of our technologies in the revised WorkProgramme. Commission Officers are very willing to discuss ideas and so when a rough draft of the project focus has been completed it will be very useful to discuss this with them. Discussion of Pre-Dic Project Evaluation Many comments on the Evaluation form were very general and not too specific / much use in re-writing the proposal. In some circumstances we only got positive comments but were given a 3½ and not higher. The lack of real time issues was the only real negative comment. On the opposite end of the scale our Potential Impact was criticised for lack of dissemination but then we scored a 4½, which is strange. Consortium was also criticised for lack of communication and control, but again we scored 4½. We got a 3½ for Relevance; and so maybe Pre-Dic did not completely fit the Embedded Systems WP objectives; Diagnostics are a little outside the objectives. The additional information we have is that about 30 projects passed the selection process although we are not sure how these were ranked. The Pre-Dic project was ranked 21 and we think that the first 15 or so will get funding. Both PREDIC and OEDECOS got 3½ for management categories. This is one area that we should easily be able to improve, for example the C.V.s of the proposed co-ordinators were not included. Another criticism of OEDECOS was that this was a space application and they thought the automotive side was weak and would therefore not be generic enough. This was possibly because it is difficult to define the objective of autonomy correctly for vehicles. Another proposal (the DICOS Project - an IP) made it past the first stage but we have been unable to get detailed feedback. There was no reply from the project co-ordinator but we believe that it is still under negotiation and an official statement is expected in February. It is hoped that if this gets funding it will become part of the landscape with respect to future projects. Projects Topics Our proposals are generally good so we should take these and consider revising them based on the feedback we received and on our continued work in these areas. The projects must closely reflect the new call text, although we do not know what this is going to be yet. If we become involved in the WP consultation process we may be able to push certain topics either individually or via MONET. Consider discussion with EUCAR and see if the areas that they promote overlap with ours. If our proposals are technology driven, then we are working the wrong way around and we need to focus on the requirements of the end user. Rather than find / provide a model-based project, we could look at the ones EUCAR are advocating. We need to get in touch with EUCAR and find out what is going on and how to get involved, this way we may have the best chance of getting involved with influencing policies. Fulvio has tried to contact EUCAR; at the time they stated their prime aim was involvement with Safety and Surface Transportation. AP1 - MONET should try to arrange a meeting, invite EUCAR and ask them to present their topics of interest and we could present how our technology could fit, compliment etc. We need to remember that the Commission Evaluators are not necessarily experts in the field and so the wording of any proposal must reflect this. If we are to try to influence the WP content then we need to be clear on the topics we want to push and to do this we should produce a half page document in the style of a proposal brief. The Commission appears happy to spend (not waste) time if anyone wants to go and see them to discuss projects and likely outcomes. They will usually be happy to supply about an hour of their time. Any chance we have of influencing this process will be considerably better if we agree on the topics as a consortium and all push for the same outcome. There is a need to focus on other technologies outside our original ideas but whatever technologies we present it must be done in terms of their 'Impact' especially on Benefits to end user / combined industry of EU / etc. If we want to have such an influence, there is not all that much time. We need to consider the EUCAR meeting and other activities we wish to adopt. We already have our list of topics and we should focus on these. Topics 1. Tools for
Knowledge Management of Technical Knowledge via Models One partner should take one topic and produce a half page document about it. Topic 1: Tools for Knowledge Management of Technical Knowledge via Models The panel discussed the issue of whether we needed to widen the scope of this topic to include non-MBD expertise and to show we can solve their problems as well as our own. The panel felt that it was best if we simply identified an interesting topic / project, but stayed mostly within our own community and only brought specific people in if the project required it and would benefit from us doing so. It was also suggested that as all the topics appear to only include Model-based Diagnosis whether the size of our group was appropriate. It was agreed that this was depended on whether the projects aims were to produce tools or standards. For standards, the group would obviously have to be widened quite considerably. Another question was raised asking that if we did approach 'Standards' then would we need to investigate non-Modelling technologies. The groups thought that this was not necessarily the case. Although sticking to our expertise was more appropriate the project could be widened by incorporating the integration and combination of tools and this would be the case whether they were model-based or not. One method of producing such a 'Global perspective' in a project may be to cover interfaces in the models and not necessarily standards as there are very few common interfaces at present. Common standards do exist between communications ECU's, but not in our area. If we take this path then it would be very important to include the suppliers. There was an initiative which involved some EU effort to describe ECU's and their functionality. If we chose this global approach then we would need to establish a connection to those activities. We could approach this area through a semantic based project by creating links and standards. This would be difficult and could take up to two years to achieve anything but has the potential to considerably reduce product development time. The panel all agreed that the topic was still very relevant, but that it could be broader than just Automotive. The topic could also potentially be integrated into another project. One fact that remains is that engineers do not want an additional tool; anything we produce needs to be integrated from the start into the design process / tools. It could also be misleading to talk about a 'tool'. The aim of the project would be a method of integrating different tools and models, from whatever source. Some kind of plug-in would be acceptable. Further work on this kind of application should look at the integration of models, which is one of the major problems facing distributed modelling. When companies receive information from suppliers (for the same vehicle) the interface is often very different. A common process needs to be established. All present agree that there is a need and an interest in this topic. ESG GmbH and R.O.S.E. GmbH will look into refining this topic. Topic 2: On-Board Systems: Integration of Control and Diagnosis; Software Solutions for Deployment of Model-based Diagnosis On-Board The emphasis of this topic should be on-board diagnosis and the methods required to derive the models and shape the process. However we need to identify a clear goal. We should use a focused title that explains the integration of Control and Diagnosis and also the process / solution, in a few short words. The panel agree that this is an essential area and that it requires development, but we may want to consider whether we should approach people outside our group with expertise in this field, for example Control and Diagnosis experts. We know that some manufacturers are putting a great deal of effort into this topic and not just with the usual model-based diagnosis people. This sort of project could be viewed as a step towards autonomy of system response, although we have not yet considered the reconfiguration aspect, which is the element that gives real autonomy. Renault already has a project looking into a transport platform to inform the driver of a vehicle that there is a problem. This system could, for instance, inform the driver to go slowly and return immediately to the garage; it could then transmit information about the car, so when the car arrives at the garage, the mechanic is ready to diagnose the problem. This data could also be used to assess wear and tear on car parts and the system could also use this information for better future diagnosis. A lot of the interest in this area is in introducing the diagnosability part of the technology into all (but especially earlier) areas of the lifecycle. When designing an electronic brake system, for instance, you need to know to add new sensors based on sensor signal information sent from the units already in operation. Distributed diagnosis is also an issue that presents problems. Many of our industry contacts report that they are quite good at designing control systems but not good at distributed diagnosis. The diagnosis they use is still very local. Although some problems will obviously be fixed locally some need a much more global view. Porsche have been investigating these interactions; they have been looking into how many ECU's can reflect a single problem. Ford is also interested in this area. There are three basic aspects to this topic and we need to look at whether we split the topic down into these areas or integrate them all into one. - Integrated
control / diagnosis We are aware that Volvo is currently investigating their understanding of control. Like other companies they are writing software that works successfully if all components are working correctly. Most manufacturers are now investigating 'Fault tolerant' Control. In other words a robust control process, not explicit diagnosis, but one that will still deliver a correct response even if it is some of the control / diagnosis systems that are faulty. Another aspect is to investigate the use of tests. In most practical applications model-based diagnosis is only done if sensor signals are received, i.e. unexpectedly. Engine control systems could be designed to carry out specific tests to determine if a problem exists. This could be one method of achieving 'Fault tolerant' Control. This is a very wide area and could be fruitful to explore. By running on-board (driver unaware) tests we could get more information on mechatronic systems in order to get a better diagnostic result. We could then investigate if this information could be integrated into the overall Control and Diagnosis process / lifecycle. The panel agrees that there is a need for research and that model-based diagnosis can make a considerable contribution to solving very real problems in this area. This area will be co-ordinated by LIPN and LAAS. Topic 3: Model-based Testing of Embedded Systems The idea behind this topic is to ascertain how we can test complex systems. At present we are unable to check a whole range of computer systems using a single tool. AUDI are very committed to this process and we know that BMW and DC also have an interest, although BMW are not sure if they have time, at present, to commit to a project. The panel feels that more automotive research is needed at EU level and that this is an area that is not strongly represented in the Framework Programme. This situation could, of course, be improved by the involvement of the panel in the consultation process for the content of the next WorkProgramme. We are aware that rail companies have the same problems as automotive companies in this topic area and we could use this to facilitate communication between the domains. The fact remains that everybody who uses embedded systems has these same problems. We should try and design a process that looks at the whole system, identifies where to test and predicts the test results of the 'correctly functioning' system. The results and the predicted results can then be compared to accurately assess the reliability of the system. Usually this testing process is carried out by human operators and so mistakes are possible, although there are some tools currently being used to remove some of the human elements. The panel decide to keep this topic but we should look into the possibility of building up a library to enable more / better testing. We must remember that our goal is not just 'a software tool' but a "silver box" which will be capable of modelling and testing the whole car. In the long term we would like the system to be capable of modelling the entire lifecycle of the vehicle and also the entire production process / plant. Testing specifications and state machines to check hardware and software could also form a part of this topic. If you only test specifications, then faults in the hardware or the process can occur if the specifications are not completely accurate. The assumption historically has been that the specifications are correct; this system should be able to test the specifications themselves during the design process. It would, of course, be easier to do this at a low level, but modelling separately at different levels may create faults. AUDI are looking into this on a higher level, i.e. for car behaviour, if this is static behaviour it should be able to be modelled and used to test system functionality through reverse engineering. The real challenge would be to integrate existing systems and not merely to supply new ones. Testing is currently done on diagnostic interfaces at a very basic level of functionality; the functionality of the complete system is not tested. We could also consider testing strategies such as discriminibility analysis; which gives solutions similar to failure modes of software. The issue of checking test covering of hardware components could also fall within this area, given the linked sub-projects across the main project lifecycle; this issue is of great importance for production processes. The overall problem remains the systems ability to identify faults. In other words, are the specifications wrong or are they just wrongly implemented. Currently tests are being written by human operators who have the faults they wish to test in mind. We need to find a system to overcome this. To do this we must also look at issues such as; - How
to capture models? The panel believe that this topic is still of considerable importance, both on its own and because of its potential effect on every other stage of design and production. This topic will be co-ordinated by AUDI AG and OCC'M GmbH. Topic 4: Preventative Diagnosis This was the area in which our FP6 project was proposed; we should learn from the issues raised by the Evaluation Panel and take this work forward. We shall investigate restructuring this topic and identify the different aspects it contains and consider whether it is best to split this into several areas, or to keep these topics clustered. Other Topics Arising from the Questionnaire - Knowledge
Management AP2: Jnt to type up minutes and circulate. Closing Discussion There are no new topics proposed by the panel but we shall ask for input from the rest of Task Group. We must now prepare and distribute the proposals and try to get the topics into the next Calls. We should also look for partners within our existing activities and investigate support from EUCAR. Workshops to determine final text of WP for next Calls. -
Embedded systems 23rd March 2004 - Workshop in Brussels AP3: Rir to find out if EUCAR will be present at Embedded Systems Workshop and if they would like to meet to discuss mutually beneficial research avenues. The Co-ordinators of each topic shall consider whether to revise their topic and then produce a summary document. These are to be less than a page long, preferably about half a page and should also contain a three line impact statement. To be sent to Luca by the end of February. Topic 1 Co-ordinated
by ESG GmbH and ROSE GmbH AP4: Topic Co-ordinators to produce half page summary of project area. AP5: We need someone to present at Brussels Embedded Systems Workshop. AP6: Rir to find out as much as possible about Brussels Embedded Systems Workshop as soon as possible. AOB Date of Next
Meeting. Possibly September; to coincide with Baden-Baden Conference.
MONET will consider taking a stall and then have the meeting the
day after.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
