IT talents in Sweden

For my Swedish readers:

Skill har skickat ut enkäten till studenter vid samtliga svenska lärosäten som har IT-utbildningar. 1140 IT-talanger har besvarat enkäten och det är deras svar som ligger till grund för denna rapport. Av de som har svarat är 20% kvinnor och 80% män. IT-talangerna är 27 år i snitt och åldersspridningen är mellan 19 och 54 år.

Improving quality with well-written requirements

I discussed with a colleague about how to improve specifications and we agreed that one of the actions that would yield quality improvements with very little investment was to educate people in our organisation on how to write good requirements.
Unfortunately such a course is not available internally at Volvo Cars (don't ask me why). But a search found some useful pages that could serve as an introduction:

• The Story of the Paperclip: Writing Good Functional Requirements from StartupCTO
• Writing Good Requirements – The Big Ten Rules from Tyner Blain
• Writing good requirements is a lot like writing good code by Jim Heumann, IBM
• Writing Good Requirements (A Requirements Working Group Information Report)
• SMART Requirements by Mike Mannion and Barry Keepence

Is software engineering immature?

Is software engineering an "immature" engineering discipline? I have often heard this both in presentations and in reading, for example SEMAT states on the homepage:

"Software engineering is gravely hampered today by immature practices."

If I draw parallels between software engineering and civil engineering (arguably the most mature engineering discipline) my spontaneous conclusion was: Yes, software engineering seems to be more like how cathedrals were built in medieval times. The construction of them were based on rules of thumb and the practical skills and experience of architects and stone masons instead of the type of engineering practices taught at universities today. Interestingly enough, one can still see the "successful" cathedrals still standing several centuries later. But it would have been impossible for the architect of  Lund Cathedral to build something like the nearby Turning Torso. So the engineering in civil engineering has certainly "matured".
But where is software engineering failing? Everyone has heard of software projects running over time, over budget or have not been used as intended (or not used at all). But wait a minute! Exactly the same thing is common within civil engineering as well. There are many examples from a single contractor renovating a small house up to world known buildings such as the Sydney Opera House:

"The original cost estimate in 1957 was £3,500,000 ($7 million). The original completion date set by the government was 26 January 1963 (Australia Day).[16] Thus, the project was completed ten years late and over-budget by more than fourteen times."

So in this respect software engineering is as immature as other engineering disciplines.
So what is the fuss about? I agree that there is no consensus in the software community on how to do the equivalence of structural mechanics calculations or stress tests. Are we more hampered by this lack of consensus on how to do engineering tasks than by the difficulty to run large projects, which seem to be common to other engineering disciplines?

Available infotainment platforms

I have previously written about various platforms for infotainment systems. I also had a slide about it in my presentation on Lindholmen Software Development day, where my point was to say that it is possible to use either a commercial platform, such as Windows Embedded Automotive or an open source such as Meego. It is a business decisions which way an OEM wants to go, not a technical.

I have probaly missed some, but here is a list of infotainment platforms available today for an OEM to build an in-vehicle infotainment system on:

• Windows Embedded Automotive, used for example in Ford's Sync.
• QNX Aviage
• Mecel Betula Suite - Automotive Bluetooth Platform
• Meego
• GENIVI, but there is little informaiton about the techical solition on the webiste. They will most likely utilise the Meego platform.
• Harman has an infotainment platform. They recenlty acquired AHA Mobile which probably will be integrated.
• There are alot of notices on using Android for in-vehicle infotainment if one searches the web, but I have not been able to find any open source software based on Android for in-vehicle use.
• Continental's Autolinq seems to be Android-based, but is not open source in the same sense as e.g. Meego, and apps must be approved (by Continental?) to be downloaded.
• Luxoft offers LUXnet, which is also Android-based, but I cannot find any information besides a press release on their homepage.

Recurring architectural decisions

A lot of academic (and industrial) research is looking at architectural decisions. One of the ideas pursued is that by capturing and managing this type of information it can be reused. I guess in practice it means that if you need to make a similar decision in the future you can look at what you decided the last time. I myself also saw this as an appealing idea. But today it struck me that we really don't have recurring decisions when we work as architects at Volvo. I think that if we had there would no be any need of an architect at all.

What we do have is a long succession of architectural decisions, each with a new set of prerequisites. The task as an architect is to be able to extrapolate from what has been done previously and still maintain some sort of conceptual integrity. To preserve the "feel" or "vision" of the architecture while still fulfilling necessary functional and quality requirements (including cost) and operate within the constraints given by for example our organisation and what is available/possible form suppliers.

Software testing

I have to admit it, I suck at software testing. I do believe in my naive notion of test-driven design, i.e. write the tests first and the program later. My problem is that I just don't have the skills of programming test cases.
Example: I wrote about the "walking skeleton" design principle some days ago.One could write a suitable set of test cases to ensure that the skeleton, with it's various units, always walks. The tests should automatically run before you check in more elaborate units, with more features in them. If the unit doesn't pass you know that you will have integration problems.

There are a lot of resources on testing out there, for example I got an introduction on creating JUnit test cases for Java programs from a colleague. Since I'm trying to learn Erlang I should probably look into EUNIT.
You should also read the blog thoughts from the test eye.

I started working with system integration testing at Volvo Cars many years ago. I learned the basics of test planning, writing test cases and report test results then. Probably very outdated since both it was ten years ago and since the automotive industry has never been on the cutting edge of software development practices. We still have a notion that a specification should be written so that it can easily be tested:

"This easily results in requirements being quantified and often in a contractual style, instead of describing the real needs and desires."

There are many other ways of Synthesizing Test Ideas!

So if experts on testing are open to the notion of having specifications focusing on understanding and real needs, why are we still clinging to contractual requirements ? Is it because of so much of the coding is outsourced in the autotmotive industry?

If one aspires to be a software architect I think working with verification & validation (testing) is a good starting point. You learn a lot about good, and bad, design when you are exposed to the errors and unintended behaviour in a system and the effects they have.

Architectural modelling

To have a more formal definition of what I mean when talking about modelling an architecture (summarised from to IEEE 1471):

An architectural description is organized into one or more views.
A view may consist of one or more architectural models. Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view.
The viewpoint determines the languages (including notations, model, or product types) to be used to describe the view, and any associated modelling methods or analysis techniques to be applied to these representations of the view.

I am not against using models to represent architectural views, but there are some fallacies that often seem to happen when using various modelling approaches in architecture descriptions.

• The purpose of the architecture model is unclear (in 1471-terminology: It is not obvious what concerns the model addresses). UML is especially problematic since it provides notation that can be used for so many purposes. Read John Daniels paper Modeling with a Sense of Purpose as an introduction.
• Everything is modelled to the same level of detail. Not everything is equally important to know. For some parts of the system it is important for the architecture (and realisation of qualities) to know the details, for other parts it is not.
• Every part of the system must be represented in the architecture, for example if every class must be traceable from some element in the architecture. This could even be a rule of the architecture, "if it is not explicitly allowed it is forbidden". This reeks very much of waterfall mindset with the architects doing much of the design before any developers get involved. I think it is presumptuous  of the architects to claim to know everything that needs to be implemented.
• Modelling tools always demands a precision in notation, which is not always desirable when sketching an architecture. You cannot model "sort of a class", or "could be a function" when using a tool, which is possible on a whiteboard or a napkin. In a tool it has to be a class, a function or a package, not something in-between.

Presentations from Lindholmen Software Development Day 2010

All presentations form the Lindholmen Software Development Day 2010 are now up on the web site. I know we were filmed as well, but I don't know when they are finished editing.

"Start with a Walking Skeleton"

I try to explain to my students that they should start with structure before programming any features. Get the OS to run with some reasonable tasks, exchange some information/messages/... between sub-systems or processes, etc.
There seems to be a proper term for this: Start with a Walking Skeleton. Apparently the term originates with Alistair Cockburn. It is often used in conjunction with the Incremental Architecture pattern.
I feel rather stupid of not knowing what others had done before, but at least I know of the concepts...

It says that this is a useful strategy for large systems. I think it is quite useful for small systems as well, especially if you are not very familiar with the features to be developed. A walking skeleton allows you to try different things in a running platform and with decent version control you can always reverse to something that is running, even if it has little customer value. And the effort of making the skeleton work is never wasted.

Ranking of Software Engineering Journals

I got a link to a ranking of the top Software Engineering Journals from my colleague Robert Feldt.
This is based on how prestigious these journals are in the scientific community based on some bibliometric index. But I would also like to see a similar ranking of how prestigious a journal is in the community of practitioners. Would it be possible to identify an index for that?

ICES-INCOSE Architecting Seminar - presentations now on-line

The material from the ICES-INCOSE-seminar: Architecting Embedded Systems is now available.
There is also a summary of of the day, including the ending panel debate, which I personally found very interesting.

More on quality attributes

Not so long ago I wrote about quality attributes. A friend on facebook gave a tip about a blog post on Software Quality Characteristics 1.0. The bloggers claim it is "the perhaps most powerful public two-page document in the history of software testing." I don't know about that but it sure is a useful document.

Trends and challenges in architecting embedded systems

Architecting is not even a proper word (I even heard someone at SPLC suggest all papers with architecting in the title should be rejected) , but is quite popular nevertheless. I think it has to do with Swedish allows you to construct a verb from just any noun, and still making sense....

I was in Stockholm to talk about architecting automotive software at an ICES-INCOSE seminar. You can find the slides from the other presenters (and mine in PDF) at the ICES homepage.
Staffan Persson is an architect from Scania and he presented a very interesting view on architecting in lean organisations (an introduction by Staffan can be found in Lean Magazine #5).

The finishing panel debate was interesting. I don't know if the notes from that will be published on the site, but I have a few reflections when thinking about it afterwards:

• One trait of a good architect is to freely move between different levels of abstraction. An architect needs to see the whole picture all the time, but he also needs to be able to dive down into details, "the devil is in the details".
• You can teach, and learn, fundamental knowledge for an architect, such expressing quality attributes, be familiar with architectural styles and patterns, know architecture platforms such as AUTOSAR or .NET, and being able to express designs in various views etc. But there are also another set of key skills that are very hard to teach, such as understanding the company culture (the common value ground), earn respect, know not only what technical parts that are affected by various decisions, but also who. So it would be difficult to move form one organisation to another an be productive as an architect.
• An architect needs to be comfortable with uncertainty. I know I am not, and this is one of my weaker points as an architect. And how do you assure other stakeholders that one should not make a decision now since we don't know enough?

Architecture for small systems?

It is Friday afternoon and I'm allowed to have some wild ideas...

After a long e-mail conversation with one student of appropriate architectural styles to use in a project course I realised that his ending comment is spot on:

I think the course and it's literature are focused on large systems and seeing that we are new to this, especially with a new language in parallel, its difficult to not apply what we learn during the course.

In my opinion the patterns covered in the book left me half way with the idea that most architectures could fit into a pattern, within its own right.

I have been too blind when I teach, and not even my professional experience helped me to identify the problem:

Most (all) literature about architecture teaches solutions for big systems.

Is there a niche for information on how to architect small systems? Small in the sense of not having millions lines of code, or a large development team, or a long project. I know that the agile manifesto states that that one of twelve important principles are

The best architectures, requirements, and designs emerge from self-organizing teams.

But do a google search on "agile architecture emerge" and see what comes up, a lot of interesting reading that suggest that the issue is not that simple.

A lot of software systems are small, from a bittorrent client (the student project) to the software in the door control unit in a car, to a mobile app. And yet they would all benefit of having some though about what they must meet for non-functional needs that is addressed by a (simple) architecture. Should I write a book on architecting small systems? So that a team member is better prepared when he or she participates in a small project where the architecture "emerges"? You don't need to be an architect to benefit from doing thinking at an architectural "level".

Quality attribute scenarios

Defining a quality attribute, a.k.a. non-functional requirement, is not easy. I know since i did that for a new platform at Volvo. When the verification and validation group comes back and says that it is not possible to verify this as a requirement I can only assume that I did not do a good enough job. But I have to agree with what George Fairbanks wrote in his blog:

Before you get too excited, you should know it’s easier to write these for quantitatively measurable qualities (e.g., throughput, latency) and harder for softer qualities (e.g., modifiability, usability).

There are two recent books that have a more agile approach to architecting: Lean Software Architecture by Coplien and Bjørnvig, and George Fairbanks' Just Enough Software Architecture: A Risk-Driven Approach. Unfortunately the latter isn't available in any Swedish internet bookstore, but as soon as I get hold of them I will post a review, as I have reviewed other books on software architecture.

Lindholmen software development day 2010

I held a presentation with the ambitious title The future of automotive software engineering at this years Lindholmen software development day.
The whole event was filmed so you can watch clips from me and the other presenters giving our talks when they are published (somewhere in the near future). Until then you can view my slides below, including the long list of references.

Architects as managers and leaders?

It is not often I write about management here, in spite of the title of the blog: "Managing..."'

I do believe that architects should not be people managers, at least not simultaneously.
However they should be leaders. An architect should have a vision of what he wants to accomplish and should lead by example. If the architect is successful it seemed like he did not do anything and everything was accomplished jointly by the developers, so don't expect too much credit as a leader...

Back to management: A former student of mine wrote about the difference between good and great companies to work for in his blog and directed me to this series of blog articles:12 Things Good Bosses Believe from Harvard Business Review.

Project presentation

I presented my project at the yearly Volvo Industrial PhD program conference last week.

How attractive it is to work as a software architect...

A colleague sent me this link from CNN Money about how attractive it is to work as a software architect. Go figure...

Hidden leaves

Philippe Kruchten wrote a very entertaining interpretation of Tao Te Ching from the perspective of an software architect. But besides being entertaining it has some very good insights into the nature of an architect, like the following:

The architect doesn't talk, she acts.
When this is done,
the team says, "Amazing:
we did it, all by ourselves!"

Personally I'm more familiar with Japanese texts (more than 20 years of budo training) so I thought of interpreting the Hagakure with the same perspective (you can find a translation to English of the original text here).

Among the maxims on the architect's wall there was this one: "Matters of great concern should be treated lightly." A senior developer commented "Matters of small concern should be treated seriously." In one's project there should not be more than two or three matters of what one could call great concern. If these are deliberated upon during ordinary times, they can be understood. Thinking about things previously and then handling them lightly when the time comes is what this is all about. To face a problem and solve it lightly is difficult if you are not prepared beforehand , and there will always be uncertainty in hitting your mark. However, if the foundation is laid previously, you can think of the saying, "Matters of great concern should be treated lightly," as your own basis for action. (1st chapter, p. 33)

According to a senior developer, even a poor programmer will become substantial in the art of writing code if he studies by imitating a good model and puts forth effort. An architect should become substantial too, if he takes a good architect as his model. (1st chapter, p. 40)

The proper manner of architecting is nothing other than not being careless, but in this way one's design will be sluggish and stiff. One should go beyond this and depart from the norm. This principle applies to all things. (1st chapter, p. 48).

In carefully scrutinising the projects of the past, we find that there are many different opinions about them, and that there are some things that are quite unclear. It is better to regard such things as unknowable. An architect once said, "As for the things we don't understand, there are ways of understanding them. Furthermore, there are some things we understand just naturally, and again some that we can't understand no matter how hard we try. This is interesting."
This is very profound. It is natural that one cannot understand deep and hidden things. Those things that are easily understood are rather shallow. (1st chapter, p. 69)

On plagiarism and referencing

In the architecture course I'm involved in several groups failed the hand-ins due to insufficient referencing when using material from other sources. In academic writing it is allowed, and even encouraged, to base your writing on data from other sources so this in itself is not wrong, but it must be done according to strict academic standards
Worst case: Incorrect or omitted references is plagiarism, which is a serious academic crime that can lead to suspension from the university.

We will arrange a workshop for all 2nd year students on Wednesday 12 October 11:00 since this is a vital skill in all courses and the thesis projects. But in the meantime I suggested they should take a look at the following introductory material:

• A crazy Norwegian introduction to the subject
• A website from the same university on searching and writing academic papers
• Read especially about referencing
• A short (15 min) hands-on video lecture on referencing

The students don't need to use any specific style of references (Harvard, IEEE, APA, Chicago, etc) as long as they are consistent.

Seminar:Trends and challenges in architecting embedded systems

I will be talking at a seminar at the Royal Institute of Technology in Stockholm 4 November: Trends and challenges in architecting embedded systems.
Besides Martin Törngren from KTH and Jörgen Hansson from Chalmers there will be speakers from Ericsson, Saab Aerospace, Semcon EIS, Scania, and myself...

InfoQ: Model-Driven Development: Where are the Successes?

I found a good blog post about more experiences onmodel-driven deleopment at InfoQ: Model-Driven Development: Where are the Successes?. Read it and the articles mentioned.

I have also read through a summary of the study of Sascha Kirstan which was very interesting.Unfotrunatley i don't know if it is avaibale on thenet yet. However both he and Jon Whittle clearly stated that in practice the advantages with model based develoipment are not so much efficiency as quality. In practice the efficiency gains tend to be around 20-30%, not 3-5 times as one can hear among certain the evangelists. And the quality gains are in the same order.
But reducing the number of faults and errors with 20% impresses me more than reducing development costs with 20%.

What is a model?

My previous post got me thinking about what a model is and why we model. I think everybody agrees that a text specification written in Word is not a model, while something in UML is.

The Cambridge Advanced Learner's Dictionary defines a model as

A representation of something, either as a physical object which is usually smaller than the real object, or as a simple description of the object which might be used in calculations.

I like the informal definition I heard from Jon Whittle last week: A model is an abstraction of the real thing for a specific purpose. However with this definition even a specification document written in Word will be a model and I don't think that makes sense.
Mellor et al. defines a model (Ludewig defines even more formal criteria):

A model is a coherent set of formal elements describing something (for example, a system, bank, phone, or train) built for some purpose that is amenable to a particular form of analysis, such as...

With this definition it is quite easy to exclude a Word document as a model, since it isn't composed of formal elements. It can incorporate diagrams based on a model, e.g. a class diagram from an UML model, but not the model itself.

In addition to this there should be a purpose with the model. John Daniels identifies three different types of models, each with a different purpose:

• Conceptual model
• Specification model
• Implementation model

When reading the article it is obvious that just by stating one has a UML model or a Simulink model really does not say anything about the purpose. What I am curios about is if one is using the same model for different purposes? Is it possible to use a model for completely different purposes with any degree of efficiency and quality? I am not talking about a transformation from one model to another, for example code generation or MDA. Do you use the same Simulink model for both conceptually understand the problem, specify properties of the solution and describe the implementation?

I had great help from my colleague Niklas Mellegård in his licentiate thesis Method and Tool Support for Automotive Software Engineering, which is defended on Thursday 30 September at 13:00 in room Torg 2, Patricia building, Lindholmen. Discussion leader will be Prof. Martin Törngren, Dept of Machine Design, Royal Institute of Technology.

Software quality attributes

I got the following e-mail from a student after discussing definitions and frameworks of quality attributes:

Hello,

It seems there are 2 main groups of ISO standards dealing with software quality:

1. a 4 part ISO 9126 standard (QA considered are reliability, usability, efficiency, maintainability, portability AND, actually, functionality)
2. second generation of ISO software quality standards referred to as SQuaRE (Software product Quality Requirements and Evaluation): ISO/IEC 25000:2005, ISO/IEC TR 25021:2007 and ISO/IEC TR 25060:2010.

I couldn't find any free copies of these standards, so we can't really use them.

Anyway, it would be interesting to get during the lectures some additional information about different quality attributes models out there (early McCall and Boehm models, FURPS, ISO models etc.).

I replied with this:

You are correct. You can't access the ISO standards (without paying).

• For a very soft introduction to quality attributes, read this: http://www.stellman-greene.com/2009/10/03/using-nonfunctional-requirements/
• An in-depth analysis of a few quality attributes are available at http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm
• For a definition of terminology I suggest IEEE std 610.12, bit this covers much(!) more than just quality attributes. It is available at http://ieeexplore.ieee.org/
• You can also read what the PhD students at Blekinge Technical University wrote down in a course about software quality: http://www.bth.se/tek/besq.nsf/pages/017bd879b7c9165dc12570680047aae2!OpenDocument
• And as usual, wikipedia is a good introduction, look at "software quality" or "FURPS" for example.

I think it will be a little too much to go into detail about different quality frameworks in this course, above they dedicated an entire course at PhD level to the subject.

Hope this helps,

Ulrik

Do you use model based development?

I heard an interesting keynote speech from Jon Whittle this morning with the title The Truth About Model-Driven Development: Who's doing it, how and why?
He presented some findings on experiences from using model-based development in industry from the EA-MDE project. I talked to him afterwards and there apparently had only been one automotive company in the study, and I personally think that the conclusions might have been different if they were more data from them. If you are working model-based in your company and want to participate in the study you can do so by answering the questionare on the project web site.
One benefit of model-based development which I expected to see in the study was that it allows domain experts to actually do implementation, for example can chassis control experts actually do code for use in ECUs.
Note: You can substitue model-based development with several other acronyms and Jon's study is still relevant; MDD, MBSE, MDA, ...

I find this study to be similar to what Sascha Kirstan is working on in the automotive industry. I participated in Sascha's study this spring and just got a report with preliminary results, which I haven't had the time to read yet. I sure hope these two researcher will look at each others result and see if they can corroborate their findings or if they are contradictions.

Jon concluded his talk with the top ten tips for companies wanting to adopt model-based development and here they are (but to truly utilise them you must know a lot more about the context where they were found):

1. Keep the domains (modelled, I assume) tight and narrow.
2. Target well known domains.
3. Put MDD on the critical path (he means that pilot projects never get sufficient attention and resources).
4. MDD works best form the ground up.
5. Be careful of gains that are offset elsewhere.
6. Don't obsess about code generation.
7. Not everyone can think abstractly.
8. Most projects fail at scale-up
9. Match tools and processes to the way people think, not the other way around
10. Ok, there was only 9...

Why I don't like formal methods...

I know the title of this port is a bit controversial and with it I alienate a lot of researchers, even at my own department. But I will try to clarify my arguments and hope that someone can prove them to be wrong.

• To be more precise; it is not the formal methods in itself I dislike, but the prominence they seem to have at prestigious software engineering conferences. I think it is not at all in proportion to how well-used formal methods are among professional development.
• Formal methods are really attractive from a researchers perspective. You can use concepts as theorem, proof and deduction and other nice things. But nice is not the same as relevant.
• Even though I have heard about formal methods as one of the enablers to establish software engineering as a "real" engineering discipline for almost ten years I still don't think they are nearer being well-established now than then.
• Some claim that you can never be sure of the software unless you can prove properties about it, and I agree that presently formal methods are the only technique that promises to do so. But there is a lot of successful software out there which have not been proven.
• Specifications that fulfil the requirement of being interpreted formally are hard to write. Compare it to learn a new programming language and be proficient enough to use it without any side effects.
• I don't know if formal methods scale well. It is one thing to use it on a nice prototype system with 30 entities developed in your lab. It is another thing to use it on a system with 500 entities, many of these with quite varying quality in requirements and code.
• I still don't know of any that uses formal methods for real; i.e. as part of the normal way in products shipped to customers in business intent on making money. Not in one-shot attempts, pilot projects or by non-profit organisations.
  A search on google skolar of industrial+software+formal+methods list papers from the 90s as the top results. And these seem more to be arguments against what I claim above rather than actual reports of usage. I really would welcome examples.

Software product line engineering

Software product line engineering is apparently about modelling variants and achieving formalism in feature descriptions. This is the conclusion I make after attending some workshops and the first morning sessions at the 14th International Software Product Line Conference in Jeju, Korea.
I presented an interesting  paper together with Håkan from Scania of how architects work with maintaining and updating existing architectures over time in the automotive industry. And we did not get a single question!
Last year when I presented another case study everybody was interested in the case and wanted to hear more from industry, but this time it didn't seem to interest the audience.
I find it quite difficult to find venues to present research based on industrial experience and not theoretical examples.

Besides that, I find the notion of feature used in many presentations different from what I am used to. To me a feature is something which is discernible for the end user, same as the definition found in the original work here. For example an adaptive cruise control is a marketable feature in a vehicle. But if I would model that similar to feature modelling prevailing here the model would consist of an optional radar, a compulsory engine, compulsory brake, etc.This means a much higher degree of knowledge about the realisation of features.

Tacit knowledge

At the ECSA conference there was a lot of talk about tacit knowledge and the importance of tacit knowledge when architecting systems.
I completely agree that one thing that differs an experienced (and productive) architect from a fresh graduate is is the amount of tacit knowledge the former possess. However I thought that in the discussions at the conference there was some confusion of what is exactly meant by tacit knowledge.
On one hand there was the view that tacit knowledge was simply the architectural knowledge that was not documented, i.e. stuff that only resided in the peoples' heads. To improve the management of this is mostly a question of capturing it in the right form and with the best tools.
On the other hand one sees tacit knowledge is such knowledge which is difficult to express using language, which is the tradition I'm used to.
In order to capture the latter type of tacit knowledge it is not just a question of having the time to do so or the right tools. The difficult part is for the person having this knowledge to be able to formulate in in such a manner that he can express it.

Meego

I have previously written about GENIVI and Moblin in this blog. I have to confess that I haven't followed the progress of either initiative.

GENIVI seems to be progressing, there is a new report on Marketing Requirements with a summary publicly available. But for an open source project it does not seem to be very open. It is interesting to note that they see themselves as different compared to a Linux platform, at least commercially.

Moblin seems to have been replaced by Meego as the in-vehicle Linux platform, with backin from Intel and Nokia. Meego had it's first release for In-Vehicle Infotainment in August this year. If I understand it correctly you can download it and run it as a infotainment system already now if you like, though I have not tried this...

I still believe that technically GENIVI will build on Moblin, or now Meego, but I cannot find anything about that on their homepage.

The future of software architecture research?

There are two areas which I judge to be of great interest to the industry regarding architecture, and I see very little interest from academia

First, how much effort should be put into architecting? In industry there never are unlimited man-power and indefinite time plans. So how do you know that you have done enough architecting? Or did too many people working with the architecture for a too long time? Or when are the gains in putting another man-hour too small to make it worthwhile?

Second, how to define an architecture based on imperfect premises? In practice the architects never have the full picture. There might be requirements missing, stakeholders unavailable or implicit constraints. Similarly the architects themselves are no super-humans, there will be inconsistencies in what they do, things forgotten, lack of crucial knowledge or personal biases, all which cause an imperfect architecture.

Personally I think that these two areas are more important from an industrial viewpoint than further software architecture research on Architecture Description Languages, formal methods or Service Oriented Architectures (the latter may be contested, but I think I am not alone).

At the 4th European Conference on Software Architecture the workshop in imperfect architecture was cancelled, probably due to too little interest (I heard only 3 papers were submitted). On the other hand I found 7 papers when I scanned the LNCS proceedings which in their title relates to the subjects above.
I don't find this very promising. Eoin Woods had a similar conclusion on the state of software architecture research at his ECSA talk when talking about the relationship between code and other design information, such as architecture, where he thought the academic research and the industrial needs are diverging and not converging.

You can also read this related column from IEEE Software: The Top 10 Burning Research Questions from Practitioners. Especially #4 "Architecture and agile—how much design is enough for different classes of problem?" should get more attention at software architecture conferences.

A colleague of mine at Volvo had an interesting proposition: Since software engineering as a dsiciplin comes from the practitioners the research community wants to keep some distance, in contrast to the "fundamental" researchers in e.g. physics who would be enthusiastic if somebody is interested in applying their theories.

ECSA 2010 pt3

The conference had three interesting keynote speakers: Jan Bosch, Philippe Kruchten and Jim Webber.

It must be quite nice to be a keynote speaker, then you have the authority of making statements like "Control is an expensive illusion causing inefficiency in the system" (JB) or "When ever you hear Service-Oriented Architecture think of orange men in rubber suits coming to rescue you" (JW) without having to prove them scientifically. Convincing and entertaining statements nevertheless.
Philippe Kruchten's keynote was a summary of the tutorial he gave together with Paris Avgeriou. The slides for both are available on-line.

ECSA 2010 pt2

I did not find this year's conference as inspiring as last year's in Cambridge. I don't know why. I think both the quality of the presentation and the gap on what was presented to industrial application varied more.
There are some papers which I plan to re-read, for example

• Lightweight and Continuous Architecture Software Quality Assurance using the aSQA Technique, on how to to architecture analysis in agile-type development.
• Experiences in Making Architectural Decisions during the Development of a New Base Station Platform
• Unifying Software Architecture with its Implementation, on the need to include architectural documentation in what actually gets maintained, i.e. the code
• Structuring Very Large Domain Models, if you think you have big models see what was studied here...
• Towards a Process Maturity Model for Evolutionary Architecting of Embedded System Product Lines, interesting but also similar to Knowit's Architecture Capability Evaluation.

The last three papers were all from the industry track (which also included the presentation by myself), which I thought was as interesting as the rest of the conference together. For some reason the industry track papers was not published by Springer in their LNCS series, but I was told they would be available at the ACM digital library.

ECSA 2010 pt1

I'm at the 4th European Conference on Software Architecture in Copenhagen. The presentations varies, both in presentation skills, scientific rigour and relevance (at least to me).

Jan Bosch stressed 3 key take-aways in his keynote last morning, he might post the presentation on his homepage:

1. An increase in speed trumps any increase in efficiency
2. Software engineering is moving from integration to composition
3. Software architecture is the key to delightful products in software eco-systems

I'm not convinced that all of his conclusions are valid outside of pure software business domains. But I guiess there are som things to learn even if one makes software for systems like cars, communication satellites etc.

Now I'm of to listen to Philippe Kruchten.

Geely owns Volvo Cars

Volvo Car Corporation is now fully owned by Geely. The deal was closed yesterday.
You can read the full story at Reuters or Gasgoo Auto News. New CEO will be Stefan Jacoby, formerly of VW North America.

Exploring variation mechanisms in the automotive industry: a case study

I supervised a thesis project on run-time variability in an AUTOSAR architecture.
You can read about the project, and download the thesis report, at the student's web site: quandoo.

Land rover Freelander 2 - Improving On The Good

 After the successful first generation Freelander 1 the Rover Group produced between 1998 and 2006, it now unveiled its successor in the Landrover Freelander 2 unveiled at the 2006 British International Motor Show. It was released in Europe in 2007 and was sold in the American markets as the Land Rover LR2.  Before getting officially announced at the motor show, the second generation Freelander was presented at the Kensington Roof Gardens in a lavish occasion featuring tennis sports celebrity Maria Sharapova before a team of journalists and media professionals.



A Better Freelander

Production of the Freelander 2 was moved from the Solihull plant in Birmingham to Halewood in England near Liverpool.  It now shared production of the Jaguar X-Type automobile.  It used a chassis based on the global midsized EUCD platform (European C/D class) that accommodated a larger transversely-mounted Volvo SI6 3.2 liter inline 6-cylinder petrol engine that also powered the new Volvo S80.

It came with 6-speed manual and automatic transmission.  The UK version didn't get this engine but instead got a 2.2 liter DW12 common rail turbo-charged diesel engine jointly developed with the French PSA (Peugeot Societe Anonyme) to power its new Peugeot Citroen cars.

With improved ground clearance and off-road handling capabilities, the second generation Freelander matched the Land Rover tradition for off-road superiority found in its Discovery and Defender line and proved superior to its European SUV rivals. In addition, the Freelander 2 sported improved interior quality, road safety features as well as modified Terrain Response off-road system used in the new Discovery III and upscale Range Rover.  The Rover Group and the Swedish Haldex Traction AB jointly developed its four-wheel drive system using the third generation Haldex coupling which was also fitted in the complete 2005 to 2008 Volvo models

The Landrover Freelander 2 was introduced in the US markets as the LR2 HSE in 2007 sporting the 6-cylinder 3.2 liter inline petrol engine capable of 230 hp on a 6-speed automatic transmission gear train.   It came with the luxurious interior appointments the US markets had become accustomed seeing in an SUV but was bettered with a Cold Climate System that heated the front windscreen and front seats at two heating levels as well as a heated windscreen water jet, a 14-speaker 440-watt surround system from Alpine, touch navigation screens, and bi-xenon headlights to mention some.
The Latest Freelander 2 TD4_e

The Rover Group launched the Freelander 2 TD4_e in 2009 which marked the first SUV in the UK to use an eco-friendly stop-start technology to economize fuel consumption and reduce CO2 emissions.  The  in the designation stands for e-Terrain Technologies presumably referring to 'earth' and was Land Rover's answer to the emerging trends in environmentally friendly road vehicles.

With the e-technology, the engine stops when in idle gear and  instantly resumes when engaging the clutch pedal. A heavy-duty starter motor acts as a generator to recover energy from its regenerative braking using capacitors to store energy and restart the engine without engaging the starter battery.  The e-Terrain is expected to be used in subsequent hybrid Freelander models.

Hot Car Commercial

Top 10 Luxury Cars In The World

Many people prefer luxury cars for their plush interiors, elegant exterior and the technology that comes with it. But let's face it, how many among us can purchase a luxury car? Not many, those of us that still want to "ride like a king" have the possibility to rent a car for a couple of days. With this article we will present 10 of the most popular luxury cars in 2009. Keep in mind that the following ranking is random.

    BMW 3 Series '“ it is offered in sedan, coupe, convertible and even a wagon version. The 2009 model comes with a face lifted exterior and here we include new tail and head lights. New for 2009 is the 335d model that has a 6 cylinder twin-turbo diesel engine. It is not only nature friendly but quite sporty.

  
Mercedes Benz C Class '“ it is the entry-luxury sedan car which was redesigned in 2009 and offered in either Sport or Luxury trim. Although an entry-level luxury car, it comes with a bunch of technologies that not only will make your riding more comfortable but it will also keep you safe.

    

Cadillac CTS '“ received a face lift back in 2008 when both the exterior and interior were changed in order to refresh the look of the car. The model also received numerous technological gizmos: DVD navigation system + touch screen LCD, Bose 5.1 Cabin Surround and a Smart Remote Start system.


 

Acura TL '“ in 2009 it reached the fourth edition and is the best selling model for the Acura Company. It comes with the brand's spanking new Super Handling All-Wheel Drive (SH-AWD) as well as new engines like the V6 3.5l 280 hp or the more powerful 305 hp V6 3.7l. Acura also included a set of new technologies like: Keyless Access System with push-button start, Acura Navigation System with Voice Recognition, AcuraLink real-time traffic, real-time weather with Doppler-style radar mapping and Bluetooth audio connectivity.

   
BMW 5 Series '“ yes, another BMW. Last year in 2009, it received a brand new look and redesigned interior. The older 525i and 525xi were replaced with the new 528i and 528xi models, each of them receiving new standard 230 hp engines. The 530i and 530xi were replaced by the 535i and 535xi, and upgraded with a 300-horsepower twin-turbo inline-six engine as standard equipment.

   Audi A4 '“ got a facelift last year which made it longer, wider and a bit lower in comparison with the older model. The new A4 received LED daytime lights and 2 new engines '“ the 2.0 liter TFSI 4-cylinder and the 3.2-liter FSI V6 engine.

   Infiniti G Sedan '“ comes with a remarkable 3.7l V6 engine capable of outputting 328 hp with a new 7 speed automatic transmission with Downshift Rev Matching, Drive Sport mode and Adaptive Shift Control (ASC). Interior changes to this model include fully revised interior trim, softer-touch lower door panels, a brighter aluminum trim color and redesigned seat heater switches.

   Hyundai Genesis '“ it is powered by either a V6 or V8 engine, the latter being capable of producing 375 hp.  It features world-class driving dynamics and the latest high-tech features at the price of entry-level premium brand vehicles. Some of the most important features are: a Lexicon 15-speaker surround sound audio system with a 6-disc CD changer; wood-trimmed leather steering wheel; ultra premium leather seating surfaces and a power glass sunroof as well as a power tilt and telescopic steering column.

 
Lexus IS '“ debuted in 1999 at the Detroit Motor Show and received the latest update last year in 2009 which includes a fresh wave exterior makeover as well as stylish and elegant interior upgrades plus improved handling. For the 2009 model, Lexus IS received the advanced Vehicle Dynamics Integrated Management (VDIM) system.

 
Jaguar XF Series - The XF is offered in three distinct trim levels: Luxury, Premium Luxury and Supercharged. The Supercharged is powered by an incredible 420-horsepower supercharged 4.2-liter V8 engine, while the Luxury and Premium Luxury trims are powered by a 4.2-liter naturally aspirated V8. All of the trims come with a modern 6 speed fully automatic transmission.



As you might have thought, the most popular luxury cars are not the most expensive ones. It is good to know that you can get quality and luxury for decent prices. We do not mean that a Maybach or a Rolls Royce are a bad choice, but paying over 300,000 $ for a car is just too much for many people.

Paris Hilton Sexy luxuries Car

Many people wonder what the contents of rest houses one of the heir to the Hilton family fortune, Paris Hilton. An American-based men's magazine, Esquire, get exclusive access to explore the luxurious home of Paris Hilton.

The tour begins quite warm. In the living room of his house, there are photographs and drawings on display everywhere. Terlhat many photos of Paris itself, which is certainly the hottest poses.

Paris entered the room, there is a table on which were displayed many photographs of Paris together with his friends. At night, the master bedroom was cold and windy. Cross the threshold to feel a bit like passing an invisible line that marks a limit of clothing stores and perfume, the scent is very soft musk roomantis.

A pair of floor fans seemed to revolve. Then there is the balcony door, which overlooks the pool and gorge on the outside of the open very wide. Below, you can see the San Fernando Valley, illuminated by a constellation of lights like in the suburbs.

Dogs Paris, Marilyn Monroe (hairy blond) and Prince Baby Bear romp with Princess Pigelette, mini pet pigs. Tinkerbell, Paris's chihuahua dog types who always carried, now living in Paris's parents' house.

"Tinkerbell was not able to be here. He was very jealous of all dogs, but every time he came and stayed with me," said Paris.

Before going to lunch at the Ivy, Paris felt as if his car is too dirty to drive, so he sprayed his car with water. On the way home from the restaurant, Paris is surrounded by paparazzi. Chase ensued as it passes through Beverly Hills. She also posed with a style like Madonna in the clip "Like a Virgin". Then, driving a blue Bentley car, and through the congestion.

worlds fastest water car

For more detail see aquada water car

Jet Car Drag Race (World Fastest women jet car drivers)

world fastest women jet Car drivers Drag RACING 1/4 Mile ,
This video will show the fact that women also have the courage in the world of racing

Solar Car Racing in Australia

Solar car or solar energy, is the type of electric vehicle that uses solar energy as a source of energy. Solar energy captured by using solar cell panels are then used to drive an electric motor that serves to turn the wheel. To be able to use stabilized then the car is equipped with solar energy storage (energy storage) is usually used batteries / battery.

All About Toyota Accessories

Even though Toyota supplies a large variety of options for consumers looking to buy a new vehicle, many people choose to customize their ride even further with parts and accessories that alter the look and feel of the car. These alterations must be done with only real Toyota accessories so that you are certain of good quality, and that the accessories you have chosen a perfectly suited for your make and model.



Every Toyota vehicle has numerous aftermarket Toyota accessories which are specifically designed to fit the vehicle. Before you buy any parts, it is necessary to know your vehicle's exact year and model name. This is because parts and accessories are designed specifically for one car and so you can't always use a 2007 Camry part in a 2009 Camry.

A few of the optional Toyota Camry parts can make your life and driving experience much more enjoyable and are quite popular among Toyota owners. These parts include remote starters for the car; permitting you to start your car and also set the inside temperature without entering yourvehicle . This is ideal in hot climates where you can use the air conditioner to cool down the car before you enter; however it is also incredibly useful in the winter to prevent you from freezing as you enter yourvehicle. Several remote starters also allow you to set the radio station as well as a number of other cool features.



A few of the internal Toyota accessories include specific shift knobs that alter the look of your vehicles interior and can make for a more enjoyable driving experience. Custom shift knobs are a great way tocustomize your interior and select the color and feel that you enjoy most. This is a popular option amongst people who enjoy driving and value a quality ride.

Toyota accessories are also available for people looking for something a little bit less flashy and a little more practical. Urgent situation aid kits which consist of every single thing you require in the case of problems while driving are popular for many motorists. These kits are full of jumper cables in addition to flashlights as well as batteries, gloves, and all of the necessary tools that might be required to do some urgentvehicle maintenance while on the road. People tend to buy urgent situation aid kits so they are always prepared in case their vehicle breaks down or they need to help somebody else with vehicle problems.



Toyota Camry parts and accessories are made for many needs and can fit almost any budget. Buying the right parts can make your driving experience safer, more efficient, and more enjoyable. When it comes to something as important as yourvehicle , make sure not to skimp on quality. Sure you can save a few bucks on inferior parts but the end result is rarely worth the savings. Invest in quality parts and, when necessary, hire a certified mechanic to install them. It's well worth your money and you won't be sorry with the results.

Books on programming embedded systems

I'm looking for a good text an programming embedded systems (for example an automotive ECU) but I can't find any that suits the bill. I was hoping to suggest something to students that avoids the trial and error learning methodology I had to endure.

A quick search on Amazon shows some which could be relevant:

• Programming Embedded Systems: With C and GNU Development Tools by Michael Barr and Anthony Massa
• An Embedded Software Primer by David E. Simon
• Embedded C by Michael J Pont
• Embedded Software Development with C by Kai Qian, David Den Haring and Li Cao

Especially the latter sounds interesting since I like the software architecture book from the same author.

I was thinking of writing a book myself on the subject. But it would mostly haven been a collection of data one can find on the internet with some detective work. Subjects to include would be:

• Introduction to C, since embedded systems are programmed in C. Period....
  I like K&R, but you can choose any book that suits the bill.
• Good coding practices in C, for example MISRA C rules.
  Read some example of MISRA C-rules here, here and here.
• RTOS basics, since this is what is used on most embedded systems.
  Read chapter 1 in the User & reference manual of rt:kernel from rt:labs for a good introduction. But personally I prefer the "run-to-completion" type of tasks which don't wait for external events for predictability.
• Interrupts, stacks, and memory handling - ISR, RAM, NVRAM, ROM, Flash and every other acronym you can think of...
• Development environments, and compilers for embedded development
  My experience is that this is pretty much decided by the OS you are using. I have experienced very mysterious bugs just by not having the correct compiler version, so I can' imagine what could happen when having a compiler from a different vendor... IAR graciously provides all of their manuals free of charge and their IDE and compilers on 30-day on a 30-day free trial.
• Various hardware on a typical embedded controller - Details on how to access hardware with code examples.
  You can see examples of typical hardware devices in the Freescale MC9S12XS256 Reference Manual, a typical automotive processor, especially chapter 10-19. Mind you that this manual is 738 pages long, so it's pedagogical value is limited.
• Debugging - Too much to cover for this blog post. This is the real dark arts...
• Architecture of embedded systems
  Almost all embedded systems are layered, but why? And how do you know which layers to have in your system? And how do you identify the tasks you should have when schedule the system?

origin of the discovery of mirror

Many biker's menggangap rearview mirror as "a display of" sheer, assuming there is also a rearview mirror to make the motor look less cool and slang.

So many of the biker off the rearview mirror or replace the rearview mirror that looks less slang, but unfortunately the mirror is not working. That kind of thing is very dangerous for the riders themselves and also endanger other motorists.


You do not know its history in the rearview mirror? Here's the history of the rearview mirror. Once in the early 1900s when the car is still a new thing, and racing cars started to grow, each participant's race car mechanic always brings.

This mechanical task is to fix the car if it breaks during the race. With the increasing development of technology, so the engine is more sophisticated and less mechanical damage and no longer needed.
Mechanical function was later changed to "observer" that help the driver. So then in charge of observing this mechanical state of the car behind them, so the driver can know if there are other peseerta car that will "overtake" them. Every car racing cars participating in this era always carried two passengers, one charge of driving a car and another charge of observing the situation behind them.

Later in the year 1911 at the Indianapolis 500 race, one participant was having trouble finding mechanics to become observers to monitor the situation backwards. As a way out he then put a mirror in his car. By using this mirror he can see if there are any other race participants will precede or nyalip. Because the transported load is lighter, the car could walk faster and finally he won the race. The next year all participants of the race car rearview mirror installed in their cars, and since then all the cars using the rearview mirror.

So for the biker who has not pakek mirror and mirror not meet the standard, plug the rearview mirror that really works. Do not wear the rearview mirror, rearview mirror or just for display only. Dangerous for other motorists and also let the police officer not on the ticket. so ... keep good buddies all vehicle glass mirror.

General Motors Board Decides To Keep European Opel Unit

Last Month General Motors Co. decided to sale their European Opel unit to Canadian auto parts maker Magna International. This month however, General Motors Co. has decided to keep Opel themselves.

This decision was made Tuesday after a long meeting in Detroit; the CEO of General Motors Fritz Henderson reported that General Motors will present its reconstructing plan forOpel to the German government soon. Magna's co-CEO Siegfried Wolf reported that Magna would continue to support both General Motors and Opel through-out the future.

General Motors has had a very tough time through-out this recession. They lost more than $8 billion through-out the past 4 years and have received $50 billion forgovernment aid. They announced the selling Opel in hope that their profit would go up in both Latin America and Asia.

At 54,000 workers and sells in cars such as Vauxhall, Opel, Cadillac and Chevrolet General Motors has the fourth highest auto sales in Europe coming in after VW Group, PSA Group and Ford Motor CO. European sales dropped 6.6 percent through the month of December and sales of Vauxhall and Opel cars have dropped even further coming in at 11.4 percent.


While General Motors had to file for bankruptcy earlier this year, Opel was kept out of the filing. Sixty-five percent of Opel was under the care of a trust while the other 35 percent was withheld by General Motors.

General Motors was not the only company having many problems during this recession. Several auto industries went into bankruptcy and were kept open due togovernment aid. Numerous companies ended up selling out some of their money making cars while others had to discontinue some famous cars. Now auto industries are beginning to pick up but they are still not doing so hot because American's just do not have the money to buy cars.

During this summer, the "Cash for Clunkers" program was a huge success among auto industries. American's were able to use their rebates so they could trade in their old gas chugging cars for a new fuel efficient one. All the while this program was great for business, when the program ended so did the business.

Unemployment rates keep rising which means more people are becoming jobless and less able to afford their mortgage let alone a new car. It is like a domino effect and it all starts with unemployment, once unemployment is figured out and American's stop losing their jobs and others find jobs, the economy will strengthen thus getting us far way for the outskirts of a recession.

So, why not figure your employment out right now? Obviously Paintless Dent Repair peaks your interest because you came to this site, since you're here I'll tell you more about Paintless Dent Repair and how you can be your own boss with your own business. Paintless Dent Repair Technicians are in very short supply, there are many cars out there and people are looking for the fastest, cheapest way to get their car fixed and back out on the road and you can help them. A technician pulls dents and dings from vehicles through glue-pulling which means there is no waiting on the sanding, painting or drying. You can ownyour own business or work out of a dealership, it's up to you. You could earn up to $100 per vehicle you fix which balances out to a nice check at the end and let's face it any money is better than no money. Don't procrastinate any longer.

Moto Gp Grid Girl Show and The historical motogp

Grand Prix motor refers to the top class of motorcycle racing, currently divided into three classes of machine different: 125cc, 250cc and MotoGP (over 990cc). Motors used in MotoGP is made specifically for motor racing, and not sold to the public (street version of the motor for 125 and 250cc classes available). This contrasts with the various production categories of racing, such as World Superbike, that feature modified versions of motorcycles available for general.

History

Road Racing World Championship was first organized by the Federation Internationale de Motocyclisme (FIM) in 1949. At that traditionally have been held several races at each event for different classes of motors, based on engine capacity, and classes for sidecars (Motor bersespan). Existing classes when it is 50cc, 125cc, 250cc, 350cc, and 500cc for single-seater racing motorcycles, and 350cc and 500cc sidecars for motorcycles. Entering the 1950s and throughout the 1960s, motorcycle engines, four did not dominate the entire class. In the late 1960s, the motor engined two did not begin to master the small classes. In the 1970s, motorcycle engines, two did not really get rid of 4 stroke engines. In 1979, Honda tried to restore the engine 4 stroke the top class by lowering the motor NR500, but this project failed, and in 1983 Honda even winning with a 500cc bike not his second. In 1983, 350cc class finally abolished. 50cc class was replaced by the year 1984 80cC class, but class often dominated by the Spaniard and the Italian was finally abolished in 1990.

Class sidecars are also excluded from the world championships in the 1990s, leaving the 125cc, 250cc, and 500cc classes.

GP 500, the premier class of Grand Prix motor racing, has changed dramatically in recent years 2002. From the mid-1970s until 2001 the top class of GP racing limited four-cylinder and engine capacity of 500cc, both types of engines 4 stroke or 2 stroke. As a result, which can survive engine is 2-strokes, produces power and greater acceleration. In 2002 for the first time, manufacturers are allowed to enlarge the total capacity of a special machine for 4 stroke engine to a maximum of 990cc, and gave freedom to choose the number of cylinders used between three to six with a certain weight limit. With the motor bolehkannya 4 990cc no, the 500 GP class renamed to MotoGP. After the year 2003 does not exist anymore two machines that do not fall in the MotoGP class. For 125cc and 250cc classes in particular still using two machines do not.

Race for the MotoGP class is currently held as many as 17 series in 15 different countries (Spain held the third race weekend). Used in the title race every weekend with several stages.

Friday free practice at the title and the first official practice, and then carried out practice Saturday both official and QTT, where the drivers trying to make the best time to record determine their starting position. Own race was held on Sunday, although there was a series of Saturday is held in the Netherlands and Qatar. Grid (row starting position) consists of three drivers per line and usually every racing series was followed by about 20 drivers. Racing held for about 45 minutes and the driver raced along the specified number of rounds, without entry to the pit change tires or refuel.