Architecture is defined as "the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution."
The architecture is an enabler to achieve certain system qualities, or non-functional properties, and many organisation view their architecture as a strategic technology asset.
An important part in designing an architecture is to identify the organisation or structure of the software and systems parts necessary for the desired qualities. If a certain design or style is used consistent throughout the design of the system it can be considered an architectural pattern. However there are reports that quality attributes are of less importance to users or customers, and this suggest that identifying and delivering competitive features may be more critical to business competitiveness.
Many systems are built on available platforms or frameworks, such as .NET for Microsoft Windows applications, Android for mobile phones or AUTOSAR\footnote for automotive software. The choice of platform constraints the design choices, but also decreases the development effort, at least in theory, and allows software to conform to explicit or implicit domain standards. The challenge for the OEM is to tailor the applications built on top of these platforms to a competitive product. In a sense these types of platforms constitute a reference architecture for a specific product or system architecture.
In this thesis a reference architecture (RA) captures the design ideas and patterns that permeates the architecture with a focus on the design decisions that have great impact on the product family as a whole, i.e. the reference architecture is a template for a specific product or system architecture
This definition of an RA is what is categorised as a ``non-structured reference architecture'' according to Angelov et al., and thus falls outside of their five types of structured RA.
An RA and a product architecture differs, among many other aspects, in that the reference architecture dictates the patterns and principles to implement, i.e. what the design should be, while the product architecture instead captures the instance of the reference architecture with deviations meeting various constraints, i.e. what the design is. Another difference between an RA and a product architecture is that the latter gives a coherent view of the product(s) in a project, possible to track the status of.
22 December 2012
21 December 2012
Thesis chapter 2.1: Ways-of-working
An OEM manufacturing and selling complex embedded systems also use a more or less elaborate R&D process to arrive at the finished design of the product. Ways-of-working refer to the both this overall process used by the organisation as a whole and to the methods and practices that teams and individual developers use within this process.
One of the most common ways to describe the overall R&D process is through a V-model or a waterfall model, with requirements elicitation, design, implementation, testing and maintenance occurring as successive activities.
A more iterative R&D process would follow a spiral model where the successive activities would be iterated, ``spiralling in'' towards the final product via a number of prototypes before delivery.
Agile processes are pushing the concept of fast iterations even further, aiming at having working software after each cycle, which typically last 2-6 weeks. There exist a number of specific agile processes, with XP and Scrum being the two most common. XP prescribes a set of practices even for the individual developers such as pair programming and continuous unit testing. Scrum focuses on the process for the team, e.g. how to prioritise and track what is being implemented.
One of the present challenges is how to scale agile from single teams to large organisations, Spotify being one example. The challenge is how to enable an entire R&D organisation to work with very short iterations when multiple teams work on the same product or systems where some customer features are realised by multiple sub-systems working together.
The most common approach to develop complex embedded systems is with an integration-centric approach, as defined by Bosch & Bosch-Sijstsema: Early in the development cycle requirements are allocated to components. The development teams implement the requirements allocated to their component. After the finalisation of the components the integration phase starts where all components are integrated to form the complete systems and system level testing takes place, where most integration problems are found and resolved.
A common way to manage a development project for MPES is to follow a stage-gate process, where the gates are driven by decisions and investment in the manufacturing of the product, i.e. driven by the hardware.
The gate progression of the development process often correspond to finalisation of software artefacts, e.g. user requirements, system requirements, software architecture, component requirements, and software implementation, i.e. a waterfall process even if the artefacts are updated as the project progresses.
One of the most common ways to describe the overall R&D process is through a V-model or a waterfall model, with requirements elicitation, design, implementation, testing and maintenance occurring as successive activities.
A more iterative R&D process would follow a spiral model where the successive activities would be iterated, ``spiralling in'' towards the final product via a number of prototypes before delivery.
Agile processes are pushing the concept of fast iterations even further, aiming at having working software after each cycle, which typically last 2-6 weeks. There exist a number of specific agile processes, with XP and Scrum being the two most common. XP prescribes a set of practices even for the individual developers such as pair programming and continuous unit testing. Scrum focuses on the process for the team, e.g. how to prioritise and track what is being implemented.
One of the present challenges is how to scale agile from single teams to large organisations, Spotify being one example. The challenge is how to enable an entire R&D organisation to work with very short iterations when multiple teams work on the same product or systems where some customer features are realised by multiple sub-systems working together.
The most common approach to develop complex embedded systems is with an integration-centric approach, as defined by Bosch & Bosch-Sijstsema: Early in the development cycle requirements are allocated to components. The development teams implement the requirements allocated to their component. After the finalisation of the components the integration phase starts where all components are integrated to form the complete systems and system level testing takes place, where most integration problems are found and resolved.
A common way to manage a development project for MPES is to follow a stage-gate process, where the gates are driven by decisions and investment in the manufacturing of the product, i.e. driven by the hardware.
The gate progression of the development process often correspond to finalisation of software artefacts, e.g. user requirements, system requirements, software architecture, component requirements, and software implementation, i.e. a waterfall process even if the artefacts are updated as the project progresses.
Thesis chapter 2: Research motivation
Embedded software is becoming increasingly complex. Ebert & Jones show that the size and complexity of software in an embedded product increases exponentially over time. Numbers from Volvo Cars show a similar exponential evolution (seen in figure the figure below), not only for the infotainment software, which resembles mobile phone features, but also for "traditional" vehicle functionality.
Ebert & Jones mention factors contributing to the complexity in their survey of the present state of embedded software development: ``combined software/hardware systems equipped with distributed software, computers, sensors, and actuators'' which points to the integration aspects of these systems.
They list "high demands on availability, safety, information security, and interoperability" as typical quality attributes.
Ronkainen & Abrahamsson also emphasise that embedded systems are characterised by the concurrent co-design of hardware and software. They stress that the `"dynamics of co-design - i.e. the way it effects the concurrent software development processes, has to be understood in order to enable the use of agile software development methods."
Manhart & Schneider describe agile development of software in buses at Daimler-Chrysler. They mention for example that "equipment, functions, or parameter sets are implemented by integrating different proportions of third party- and OEM manufactured components" indicating supplier involvement. In their paper they also point out that software realises "complex electric or electronic functions", e.g. the integration between hardware and software.
The domain of large industrial development of mass-produced embedded systems can thus be defined by five characteristics:
Broy states some challenges that automotive software is experiencing: "The high intensity of software in cars puts the car industry under stress and a high change pressure." He continues that the trend is not close to an end, and is driven by e.g: "High demand of new innovative or improved functionality'', "shorter time-to-market'' and "increased individualization".
In addition to these challenges the development of MPES exhibit some inherent problems for the R&D organisation, amplified by the present ecosystem of specialised suppliers and OEMs acting as system integrators:
The choice of focusing on ways-of-working, architectures and ecosystems was done for three subjective reasons: In my experience it is easier to change these aspects than e.g. culture, knowledge management, or organizational structures. My engineering background made it easier for me to analyse and develop artefacts in these areas. This is a thesis in software engineering, and all these three areas are well within this field of research.
 | |
| Software in Mbytes downloaded in a vehicle at production at VCC over the years. |
Ronkainen & Abrahamsson also emphasise that embedded systems are characterised by the concurrent co-design of hardware and software. They stress that the `"dynamics of co-design - i.e. the way it effects the concurrent software development processes, has to be understood in order to enable the use of agile software development methods."
Manhart & Schneider describe agile development of software in buses at Daimler-Chrysler. They mention for example that "equipment, functions, or parameter sets are implemented by integrating different proportions of third party- and OEM manufactured components" indicating supplier involvement. In their paper they also point out that software realises "complex electric or electronic functions", e.g. the integration between hardware and software.
The domain of large industrial development of mass-produced embedded systems can thus be defined by five characteristics:
- Deep integration between hardware and software for significant parts of the functionality
- Strong focus on manufacturing aspects of the product during development (e.g. by project gates)
- Strong supplier involvement providing a majority of the parts, and associated value, of the finished product
- Some parts of the software and hardware realise safety-critical functionality
- Long production life-time, sometimes spanning years for a single product model
Broy states some challenges that automotive software is experiencing: "The high intensity of software in cars puts the car industry under stress and a high change pressure." He continues that the trend is not close to an end, and is driven by e.g: "High demand of new innovative or improved functionality'', "shorter time-to-market'' and "increased individualization".
In addition to these challenges the development of MPES exhibit some inherent problems for the R&D organisation, amplified by the present ecosystem of specialised suppliers and OEMs acting as system integrators:
- Heavy reliance on external developers and subcontractors complicates coordination through process because each of them use their own processes.
- Outsourcing of significant parts of development to suppliers causes expensive communication and coordination delays during integration. The cause of this is each issue found must be resolved through an OEM-supplier roundtrip with the OEM identifying the issue, discuss with the supplier(s) who resolves it, and the OEM re-integrating the "fixed" parts.
- The exponentially growing feature content severely complicates "big-bang" integration because used architectures requires all parts to be present for the system to work and therefore testable.
The choice of focusing on ways-of-working, architectures and ecosystems was done for three subjective reasons: In my experience it is easier to change these aspects than e.g. culture, knowledge management, or organizational structures. My engineering background made it easier for me to analyse and develop artefacts in these areas. This is a thesis in software engineering, and all these three areas are well within this field of research.
20 December 2012
Thesis chapter1: Software in mass-produced embedded systems
Software is prevalent in many products manufactured today; cars, washing machines, mobile phones, airplanes and satellites (link to paper), the embedded software controls the behaviour of the product and is often critical for the success of the product.
Typically these products are developed in large, and sometimes very complex, industrial projects where the manufacturing and delivery of the product in general is a heavier investment than the software budget. In the automotive domain the purchasing and manufacturing cost of the physical parts for each product is typically an order of magnitude higher than the R&D cost split over the number of products built.
This in turn tends to drive the entire R&D process, and software follows the process logic of the mechanical development and manufacturing setup.
Software differs compared to its mechanical and electronic counterparts; once the software is developed there is no additional cost if one increases the number of products produced.
Likewise, the cost of updating or replacing software in an already built product is orders of magnitude cheaper compared to replacing hardware.
The common business model is to sell the manufactured system as a product, the original equipment manufacturer (OEM) gets paid an agreed amount for each system delivered. From a customer perspective there are some issues with this present business model when it comes to features purely relying on software. An example scenario in the automotive domain could be:
With more and more vehicles becoming connected it is conceivable to have continuous updates with new software features to customers on a scale and to a cost that is impossible would the updates require hardware modifications. This would build trust in the brand to maintain a useful product and extend the value for the customer after the purchase.
The team developing Google music could deploy it after 3 months of development, making it ``almost competitive'' with smartphones. More and more services are used regardless if one is using the phone or driving in a car, and from a customer perspective it is difficult to understand why services in one context is cannot be delivered in another.
The topic of investigation in this thesis is efficient and sustainable development of software for mass-produced embedded systems (MPES), and the implications a chosen way-of-working and software architecture have on R&D, and indirectly on the business.
Typically these products are developed in large, and sometimes very complex, industrial projects where the manufacturing and delivery of the product in general is a heavier investment than the software budget. In the automotive domain the purchasing and manufacturing cost of the physical parts for each product is typically an order of magnitude higher than the R&D cost split over the number of products built.
This in turn tends to drive the entire R&D process, and software follows the process logic of the mechanical development and manufacturing setup.
Software differs compared to its mechanical and electronic counterparts; once the software is developed there is no additional cost if one increases the number of products produced.
Likewise, the cost of updating or replacing software in an already built product is orders of magnitude cheaper compared to replacing hardware.
The common business model is to sell the manufactured system as a product, the original equipment manufacturer (OEM) gets paid an agreed amount for each system delivered. From a customer perspective there are some issues with this present business model when it comes to features purely relying on software. An example scenario in the automotive domain could be:
My neighbour bought a new Volvo four months after I did.Another example scenario would be
He got Spotify, but I didn't.
Do I feel ``cheated''?
Google music turns out to be the next hot thing. It takes Volvo 30 months to include this feature according to the present stage gate process. Is the feature still ``fresh'' when delivered?A future scenario could be that Spotify is deployed to customers independently of when the car is built in the factory, i.e. after the customer has received the vehicle.
With more and more vehicles becoming connected it is conceivable to have continuous updates with new software features to customers on a scale and to a cost that is impossible would the updates require hardware modifications. This would build trust in the brand to maintain a useful product and extend the value for the customer after the purchase.
The team developing Google music could deploy it after 3 months of development, making it ``almost competitive'' with smartphones. More and more services are used regardless if one is using the phone or driving in a car, and from a customer perspective it is difficult to understand why services in one context is cannot be delivered in another.
The topic of investigation in this thesis is efficient and sustainable development of software for mass-produced embedded systems (MPES), and the implications a chosen way-of-working and software architecture have on R&D, and indirectly on the business.
Thesis: Preface
I promised to post my thesis in a previous post. I hoped to have done so already last week, but things don’t always go according to plan. Here is at least the preface.
I don’t know if I should post a new chapter every day during Christmas, if I want to attract readers interested in development of software for embedded systems I guess this it’s not the best period.
This thesis is the result of my conviction that there was an untapped potential of improving present software development in the automotive domain, based on 10 years of industrial experience at Volvo Car Corporation.
The research project described in this thesis started with a goal of improving the architecture process and the management of software architectures in the automotive domain.
The goal evolved as the project progressed to use the right architecture as a means to improve the overall software development process in order to enable shorter leadtimes and to develop and release new features at a sustainable pace indefinitely.
I started the research project with the assumption that one of the main reasons for the automotive domain of not adopting best practices from other domains is that this domain has very different prerequisites compared to other domains, in the form of business practices, architectures and product properties. An assumption that I have completely reversed since I could find nothing in my empirical data supporting it when I compared with published cases form other domains.
The only reasons left that could explain this is a culture of “not invented here” in the automotive domain when we are looking at how software businesses, architectures, processes and teams play out in other domains.
Hopefully this thesis could be a step towards a better understanding that the automotive domain has more in common with other domains of software-intensive systems, than differences.
27 November 2012
Hiatus
The blog has not been updated at all in the last few months. This has many reasons, with the main being me trying to finish my thesis.
I hope to have a coherent draft ready in just a few weeks and plan to post the chapters of the summary as blog posts in December. Comments are appreciated (if there still are any readers out there).
Subscribe to:
Posts (Atom)