Electric drives are used to control electric motors, which are pervasive in industrial applications. In this paper we propose enhancing the electric drives to fulfil the role of fog nodes within a Fog Computing Platform (FCP). Fog Computing is envisioned as a realization of future distributed architectures in Industry 4.0. We identify the system-level requirements of such an FCP, including requirements that are extracted from the current architecture of drives, which we consider as a baseline. These requirements are then used to design a system-level architecture, which we model using the Architecture Analysis & Design Language (AADL). We identify the "technology bricks" (components such as hardware, software, middleware, services, methods and tools) needed to implement the FCP. The proposed fog-based architecture is then used to implement a Conveyor Belt industrial use case. We evaluate the resulting use case on several aspects, demonstrating the usefulness of the proposed fog-based approach. By developing the electric drives as fog nodes, that we call fogification, new offerings like programmability, analytics and connectivity to customer Clouds are expected to increase the added value. Increased flexibility allows drives to assume a larger role in industrial and domestic control systems, instrumenting thus also legacy systems by using drives as the data source.

Since April 2014 the Artemis/ECSEL project EMC2 is running and provides significant results. EMC2 stands for "Embedded Multi-Core Systems for Mixed Criticality Applications in Dynamic and Changeable Real-Time Environments". In this paper we report recent progress on technical work in the different workpackages and use cases. We highlight progress in the research on system architecture, design methodology, platform and operating systems, and in qualification and certification. Application cases in the fields of automotive, avionics, health care, and industry are presented exploiting the technical results achieved.

Software and systems product line engineering (PLE) has been an established approach for reducing time to market as well as cost and increasing quality in a set of related products for two decades now. Although there is a huge body of knowledge on PLE, adopting a concrete PLE approach is still not a trivial endeavor for interested companies. With the increasing importance of development speed, the advent of agile engineering approaches, and decreasing management interest in improvements that require large organizational transformations and only show benefits after several years, companies are facing challenges in successfully adopting this approach. They often hesitate as there is no clear adoption path, nor any certainty, that the intended improvement steps will also provide added value in the short- and mid-term perspective. In consequence, a considerable amount of PLE potential still remains unexploited.

Many approaches to software product line engineering have been founded on the development of a single product line platform. However as customer requirements change and new products are added to the product line, software producers recognize that the platform cannot be "stretched" indefinitely and a significant problem is striking a balance between development efficiency by increasing platform commonality and customer dissatisfaction from products with additional undesirable features and properties.

Many organizations have started to use agile development processes to speed up the development cycle and to improve the ability of the company in reacting to changing requirements. Adopting agile practices may happen as a revolution where all old practices are removed or as a more gradual process. In this paper, we discuss lessons learnt in two agile transition processes. Based on our experience, agile processes can be used in embedded software development for products. The challenges include the varying size of user requirements, the role of system requirements, and architecturally significant requirements. It is difficult for large organizations to be agile. Work allocation for a large number of different teams with different competencies tends to decrease speed, and increase the role of design and management. We conclude that agile development in this context needs very skilled developers and has to be a combination of new and old practices.

Large industrial product lines may produce tens of thousands of variants each year. Each variant typically contains both reusable assets as well as product specific code created by different organizational units. To produce this vast number of variants the organizational resources must be used efficiently. For roadmapping this means an ability to schedule production of reusable assets so that all variants can be completed according to their requirements. When aiming for centralized variability management, roadmapping requires effective management of product line feature dependences and priorities. In this paper, we first introduce the problems haunting feature roadmapping in industrial product lines. Then we investigate how these problems can be solved using a novel approach for organizing product lines based on our practical experiences. Finally, we discuss our experiences and compare our approach with results by other researchers.

Architecture has been identified as a main tool for high quality system development. It encapsulates the earliest design decisions of the system under development. However, these decisions heavily constrain the overall design space; therefore it is worth emphasising the reasons behind architectural choices. Methods for architecture have been suggested by various research. Unfortunately, they fail to achieve frameworks that can reason about the strong relationship between general system goals and the decisions that are made to fulfill those requirements. In this paper, we have three major contributions: (i) we introduce a general framework for the architectural design cycle. This framework describes an iterative process that assists in transforming system-wide goals into effective architectural description that satisfies the main requirements. (ii) We show how the prioritizations among goals and environmental constraints have a major impact on the resulting architecture. In addition, we demonstrate that the ordering of design decisions greatly affects what kind of structure is created. We describe how properties of earlier design decisions constrain the available design space and the concerns emerging from the current design guide selection of the next design choices. (iii) We investigate how this framework can be adapted in a concrete design example. We conclude that using this model can improve traceability, support trade-off decisions and record design rationale.

Contemporary software engineering utilizes product lines for reducing time to market and development cost of a single product variant, for improving quality of the products, and for creating better estimations of the development process. Most product line development processes rely on performing a domain analysis to find out commonalities among proposed family members and to estimate how they will vary. On the other hand, most requirements engineering methods focus on the specification of a single system. Despite active research efforts to close this, gap there is still no effective method that allows product specifications in arbitrary levels of detail for a hierarchical product family. In particular, it is not possible to combine different specification mechanisms to produce a complete family specification. The authors approach these problems by presenting a method that allows system specifications both in the product line variant as well as the product family level. This exposes many problems in managing consistency between different methods to specify families of systems. To achieve this, our method offers derivation of consistency management support between different specification levels and among family variants.

In search for improved software quality and high productivity, software reuse has become a key research area. One of the most promising reuse approaches is product families. However, current practices in requirements engineering do not support product families. This paper describes a definition hierarchy method for requirements capturing, structuring, analysis and documentation. This method helps to identify architectural drivers of the product family and shows how different products in the family vary.

Nokia Research Center (NRC) has been leading Esprit project ARES (Architectural Reasoning for Embedded Systems) for two years. One of the main purposes of ARES is to demonstrate the use of architectural modeling in controlling properties of industrial scale products and product families. Two examples are documented. Forward architecting was applied in modeling the new architecture for our mobile phone family showing how to control the dynamic properties of the software. Reverse architecting was used to tune the performance of our telephone switch software. Both cases show that special purpose models can be constructed even for very large systems and they do give valuable insight to the properties of the software.

In distributed applications, several processes are involved in serving a request. The state of the request is encoded in the states of their processes. This can lead to unnecessary complexity and hard-to-detect errors. This paper presents an architectural style, token architectures, that decouples data, control and synchronization. Tokens encapsulate the state of a computation. Service points manipulate the tokens and perform services for them. The tokens use maps to move between service stations. We show in an example how this style simplifies the design of a telecommunications application and what difficulties traditional designs must solve.

The paper briefly presents the OCTOPUS method which is about merging two up-to-date, highly independent and rapidly advancing technologies: object-oriented methods and real-time systems. It can be used for systematically developing the software of embedded real-time systems gaining the benefits of the object-orientation as commonly reported for the development of other branches of software, but matching also the specific requirements of real-time systems.