On this page you’ll find the journey of impuls3. Where it started, who was involved, significant events, influential people, principles, reasoning and more. The names in this text are fictitious. I’m sure that the people that have played a role, will recognize themselves in the story. At the end of each chapter References are given and pearls that contribute to the Impuls3 method (Impearl3). I hope you’ll have fun in reading it and, in the end have a better understanding what impuls3 is all about. At this moment (2023) the content is very much sketchy. I am still finding ways the present the story in a readable manner, and at the same time to keep track of the events that led to the impuls3 model.
— Cees Michielsen
Where it started …
Back in the mid 80’s I joined Philips Electronics. At that time still a multinational company with a a great diversity of products for the Consumer market, Healthcare, Business electronics, Semiconductors, Lithography, Lighting and many more. Typically a company that cared not only for its workers, but also for their families. Providing housing, alternative work environments for partners of the workers in case they had to move closer to the office. As they did for us.
It was a warm welcome.
As a starting software engineer I found myself amidst mechanical and electrical engineers. For me this was entering the world of systems engineering for the word go. The term systems engineering was not used at that time, also mechatronics was not yet introduced. The product development process was traditionally led by the mechanical department, followed by electronics and usually much later by the software group. As a software group we weren’t even sure if we were allowed to us the term ‘engineer’.
I was hired by one of Philips’ brilliant minds (and not just because he hired me ;-), let’s call him Jeff. Our team of about 80 people was responsible to develop and manufacture so-called ‘pick-and-place’ robots, mainly for the automotive industry. One of Jeff’s ideas was instead of using a single multipurpose robot for all placement actions, to use several robots in parallel. In this way not only the complexity of the robots themselves was reduced, but the performance in terms of throughput was improved significantly.
Sixteen robots were positioned next to each other and could in that way work independently from one another. Each of them picking a dedicated set of electronic components and placing them onto a printed circuit board.
Our team was finding ways amongst others, to optimize the movements of the robots, and as a result of that group the reels (feeders) with these electronic components and virtually shuffle them around as long as it would take to find that optimum.
One of the great benefits of working as a relatively small division in a large company, is to use the facilities.
The Wall
Every few years the machines would be demonstrated at the Productronica exhibition in Germany. A select group of about 20 – 30 employees was allowed to go there, either to support the exhibition team or to observe the competition. I was lucky to be part of that group in 1989. The exhibition was held in Munich in November.
I remember that our latest model (the FCM) wasn’t quite ready yet to be shown in full blown operation, but to give potential customers a sneak preview one of the models was tucked away behind the scenes and covered with a cloth.
Going back to the hotel after a long day, on every tv channel the same pictures were shown of people climbing a smashing the Wall that separated east and west Germany for such a long time. Only in hindsight I realized what I had witnessed from close by.
On Saturday I bought a newspaper, the Frankfurter Allgemeine as a kind of souvenir. I will always remember the title: “Mauer und Stacheldraht trennen nicht mehr“
When we drove home in the bus, we made a game of who could spot the most Trabant’s.
The Italian job
When I arrived at the airport in Turin, I was welcomed by a large poster showing that FIATs latest model, the Punto, had arrived. È arrivata. Punto. — She has arrived. Period.
My job was to assess the Electrics & Electronics development department (EE) for their compliance to the Capability Maturity Model Integrated (developed by Carnegie Mellon University, nowadays by the CMMI institute). Punto? Se n'è andata!. — Punto? She’s gone!
Resource arbitration
During the assessment a fair amount of customer complaints surfaced. Their cars wouldn’t start after being left idle for a few weeks during the holiday season. There appeared to be an problem in the electronic windows control system, even when the car was not used it leaked small quantities of electricity. After a few weeks the battery would be drained, hence the engine could not be started.
The investigation that followed brought similar situations to the light. It was clear that the battery system did not discriminate where the requests for electrical power originated. No arbitration took place. Resolving the issue not only required measures for the windows control system, but also for the battery system. It was important that the battery system was able to give priority to some of its consumers, like the starter motor. In this way the battery control system was able to guarantee a minimum amount of electrical energy to start the car1.
The Miracle of Eindhoven
The ideas and concrete deliverables for something that you would call a method emerged during the work at DAF Trucks in Eindhoven. I was one of DAF’s advisors that took part in the V-cycle initiative. A project that was created to ensure that the development department (all disciplines) acted at Automotive SPICE level 3. Automotive SPICE is Capability Maturity model, comparable to the CMMi. My contribution was limited to the Quality and the Requirements Engineering working groups. I soon found out that these two process groups had a lot in common and were able to support one another. At the start of the project an estimate needed to be made of the amount of requirements specifications that must be made and for which system elements. The term System Element was chosen for the identification of entities that need a requirements specification, from the highest level: vehicle to the lowest level part and everything in between.
One of the group leads, say Tom, had the idea of defining abstractions of the vehicle at various levels. Each level would represent the complete vehicle, but expressed with different means, different levels of detail.2
Abstraction levels
At the vehicle level one system element was identified: the vehicle. At the first level of vehicle level decomposition
Design artifact quality
During the course of the project we were asked to think about the quality of the various design artifacts that we had defined so far.
High tech stuff
System Requirements Engineering
Since 2014 the High Tech Institute has adopted ITIB’s System Requirements Engineering training. It appeared to be a friendly, low threshold, tool-independent way to share all that is happening in the Requirements Engineering domain.
Systems Thinking
In 2018 a request from the Technical University of Eindhoven to create a course on Systems Thinking for a post-master curriculum.
Footnotes
