Configuration capabilities are important for modern advanced network services. Network conditions and user populations have been significantly diversified after decades of evolution of the Internet. Configuration capabilities allow network services to be adapted to spatial, temporal, and managerial variations in application requirements and service operation conditions. Network service providers need to decide on the best configuration. Ideally, a network service should have all of its components optimally configured to most effectively deliver the functionality for which it was designed. The optimal configuration, however, is always a compromise between different metrics. To decide on an optimal configuration, the prominent performance and cost metrics must be identified, modeled, and quantified. Optimization objective functions and constraints that combine these metrics should be formulated and optimization techniques should be developed. More important, in the scenarios where the application requirements and system conditions change over time, the service configuration needs to be dynamically adjusted and strategies that guide the reconfiguration decisions need to be developed. Because the actual process of configuring a network service incurs configuration costs, an optimal reconfiguration strategy should be one that achieves a tradeoff between the (re)configuration costs and static optimization objectives. Furthermore, such tradeoffs must be based on the consideration of long-term benefits instead of short-term interest. This thesis focuses on understanding the strategies for dynamic (re)configuration of advanced network services positioned above the Transport Layer. Specifically, this thesis investigates the configuration and more important dynamic reconfiguration strategies for two types of advanced network services: Service Overlay Networks, and Content Resiliency Service Networks. Unlike those network services whose configuration involves mainly arrangement of hard-wired components, these network services have the ability to change service configuration in small time scales. This makes the modeling of application requirements and system condition dynamics not only possible but also meaningful and potentially useful. Our goal is to develop modeling and optimization techniques for network service configuration and dynamic reconfiguration policies. We also seek to understand how effective techniques can improve the performance or reduce the cost of these advanced network services, thus demonstrating the advantage of allowing configurability in these advanced network services.

When choosing what IoT protocol to use today, there are lots of choices. If a mesh type network is chosen, Bluetooth mesh might be a possible candidate. Bluetooth mesh without correctly configured parameters can however suffer from congestion and packet loss if the network is very dense or consists of many nodes. This can be counteracted by choosing which nodes should be relays more carefully, as well as setting the re-transmission count and Time To Live (TTL) based on the current topology of the network. If the nodes in the network change position or are added/removed regularly, it is impossible to set the parameters optimal for all the possible network layouts. This is where a dynamic configuration comes in handy. In this master thesis a custom control model was created which implemented the K2 Pruning algorithm for relay selection, custom heartbeats for a dynamic TTL on each node, and a static re-transmission count for message originators and relays. A possible way to implement a dynamic re-transmission count is also discussed, as well as how the dynamic configuration could be autonomous without the need of physical interaction when reconfiguring the network. The implemented dynamic configuration tested on a physical system of 33 nodes was partly unsuccessful, but still provided improved Packet Delivery Ratio (PDR), reduced message delay, and useful knowledge for future implementations of a dynamic configuration. The K2 Pruning algorithm failed in choosing relays correct and quickly due to congestion during the neighbor information exchange needed to run the algorithm. Therefore, a different relay selection algorithm is suggested for future models or the refrain of acknowledged messages during the neighbor information exchange phase.

The development of embedded software in the automotive industry has reached a level of complexity, which is unmaintainable by traditional approaches. The AUTomotive Open System Architecture (AUTOSAR) was created to standardize the automotive software. In this architecture, the development of software is spread, in general, between three different entities: Original Equipment Manufacturers (OEMs), e.g. Volvo; Tier-1 Suppliers, such as Vector; and Tier-2 Suppliers, for example, Renesas Microelectronics. Another methodology that has emerged is to develop Electronic Control Units (ECUs) domain wise: infotainment, chassis & safety, powertrain, and body and security. To allow inter-domain communication, the state of art for fast and reliable communication is to use a gateway ECU. The gateway ECU is a crucial component in the electrical/electronic (E/E) architecture of a vehicle. In AUTOSAR, a third party, different from the car manufacturer, typically implements the gateway ECU. A major feature for a gateway ECU is to provide highly flexible configuration. This flexibility allows the car manufacturer (OEM) to fit the gateway ECU to different requirements and product derivations. This thesis investigates the implementation of post-build configuration for a gateway ECU. First, the thesis provides the reader with some background on AUTOSAR and the current E/E architecture of the gateway ECU. The protocols used by the gateway are explained. The design of a potential solution and its implementation are discussed. The implementation is evaluated through regression tests of the routing functionality. Processing time, memory use, and scaling of the solution are also taken into account. The results of the design and the implementation if judged adequate could be used as a springboard to allow post-build in an existing gateway ECU architecture. The results could consolidate the path towards full conformance to AUTOSAR. / Inbyggda system har ökat i fordonsindustrin. Utvecklingen av dessa inbyggda programvaror har varit komplex och är inte genomförbar per enhet. Idag är utvecklingen gjort av tre foretag: en OEM (Original Equipement Manufacturer), Tier-1 leverantorer som tillhandahaller mjukvara till OEMs, Tier-2 leverantorer som tillhandahåller elektroniska styrenheter (ECU) hardvaror. Förmedlingsnod ECU är en viktig komponent i ett fordons elektriska/elektroniska (E/E) arkitektur. En tredje part implementerar, som skiljer sig från OEM, de flesta funktionerna av den förmedlingsnod ECU. En viktig egenskap för en förmedlingsnod är att tillhandahålla en mycket flexibel konfiguration. Denna flexibilitet tillåter (OEM) att anpassa förmedlingsnod till olika kraven och fordonarkitekturer. Denna avhandling undersöker genomförandet av Post-build konfigurationen, ocksa kallad dynamisk konfigurationen för en förmedlingsnod ECU. För det första gers bakgrund på AUTOSAR och den nuvarande E/E arkitekturen för den ECU. De kommunikation protokoll som används förklaras. Utformningen av en potentiell lösning och dess genomförande diskuteras. Implementeringen utvärderas genom regressionstest av routingsfunktionaliteten. Behandlingstid, minneseffektivitet och skalning av lösningen beaktas också. Resultaten av konstruktionen och genomförandet om det bedömdes som lämpligt skulle kunna användas som ett springbräda för att möjliggöra postbyggnad i en befintlig förmedlingsnod arkitektur. Resultaten kan konsolidera vägen mot full överensstämmelse med AUTOSAR. / Le développement de systèmes embarqués dans l’industrie automobile a atteint un niveau de complexité très élevé. D’où la nécessité de créer de nouvelles méthodologies. AUTomotive Open Architecture (AUTOSAR) a été créé pour la mise place de standards pour le développement dans l’industrie automobile. Dans l’architecture AUTOSAR, le développement de logiciels embarqués est reparti, en général, entre trois partis : Original Equipement Manufacturer (OEM), Renault par exemple. Le deuxième niveau regroupe les fournisseurs de logiciels et outils, par exemple, Elektrobit. On retrouve en troisième position les Tier-2 suppliers, fournisseurs de cartes électroniques pour l’automobile, comme Renesas ST. Le développement de calculateurs est séparé par domaine : Multimédia, châssis, motorisation et intérieur. La communication inter-domaine passe par un calculateur passerelle. Le calculateur passerelle est essentielle dans l’architecture électronique du véhicule. Dans AUTOSAR, le calculateur est fourni par un tiers parti, différent du constructeur automobile. Il est donc nécessaire pour le constructeur d’être capable de configurer le calculateur passerelle, sans repasser par le vendeur. Par exemple, le constructeur peut décider, réception du software de rajouter une nouvelle route dans la passerelle. Cet aspect est connu sur le nom de Post-build Configuration dans AUTOSAR. Le but de ce stage est le design et l’implémentation de Post-build configuration d’un calculateur passerelle. D’abord, AUTOSAR et l’architecture électronique d’un calculateur passerelle sont détaillées. Les protocoles de communication sont aussi décrits. Ensuite, le design et les choix d’implémentation sont discutés. L’implémentation est évaluée avec des tests de régression sur les fonctionnalités de routage. Aussi, la solution finale est évaluée sur les critères de performance de routage, l’efficacité en consommation mémoire et la capacité d’être intégrée dans un produit final.

The development of embedded software in the automotive industry has reached a level of complexity, which is unmaintainable by traditional approaches. The AUTomotive Open System Architecture (AUTOSAR) was created to standardize the automotive software. In this architecture, the development of software is spread, in general, between three different entities: Original Equipment Manufacturers (OEMs), e.g. Volvo; Tier-1 Suppliers, such as Vector; and Tier-2 Suppliers, for example, Renesas Microelectronics. Another methodology that has emerged is to develop Electronic Control Units (ECUs) domain wise: infotainment, chassis & safety, powertrain, and body and security. To allow inter-domain communication, the state of art for fast and reliable communication is to use a gateway ECU. The gateway ECU is a crucial component in the electrical/electronic (E/E) architecture of a vehicle. In AUTOSAR, a third party, different from the car manufacturer, typically implements the gateway ECU. A major feature for a gateway ECU is to provide highly flexible configuration. This flexibility allows the car manufacturer (OEM) to fit the gateway ECU to different requirements and product derivations. This thesis investigates the implementation of post-build configuration for a gateway ECU. First, the thesis provides the reader with some background on AUTOSAR and the current E/E architecture of the gateway ECU. The protocols used by the gateway are explained. The design of a potential solution and its implementation are discussed. The implementation is evaluated through regression tests of the routing functionality. Processing time, memory use, and scaling of the solution are also taken into account. The results of the design and the implementation if judged adequate could be used as a springboard to allow post-build in an existing gateway ECU architecture. The results could consolidate the path towards full conformance to AUTOSAR. / Inbyggda system har okat i fordonsindustrin. Utvecklingen av dessa inbyggda programvara har varit komplex och ar inte genomforbar per ett enhet. Idag ar utvecklingen gjort av tre foretag: en OEM (Original Equipement Manufacturer), Tier-1 leverantorer som tillhandahaller mjukvara till OEMs, Tier-2 leverantorer som tillhandahaller elektroniska styrenheter (ECU) hardvaror. Förmedlingsnod ECU är en viktig komponent i ett fordons elektriska/elektroniska (E/E) arkitektur. En tredje part implementerar, som skiljer sig från OEM, de flesta funktionerna av den förmedlingsnod ECU. En viktig egenskap för en förmedlingsnod är att tillhandahålla en mycket flexibel konfiguration. Denna flexibilitet tillåter (OEM) att anpassa förmedlingsnod till olika kraven och fordonarkitekturer. Denna avhandling undersöker genomförandet av Post-build konfigurationen, ocksa kallad dynamisk konfigurationen för en förmedlingsnod ECU. För det första gers bakgrund på AUTOSAR och den nuvarande E/E arkitekturen för den ECU. De kommunikation protokoll som används förklaras. Utformningen av en potentiell lösning och dess genomförande diskuteras. Implementeringen utvärderas genom regressionstest av routingsfunktionaliteten. Behandlingstid, minneseffektivitet och skalning av lösningen beaktas också. Resultaten av konstruktionen och genomförandet om det bedömdes som lämpligt skulle kunna användas som ett springbräda för att möjliggöra postbyggnad i en befintlig förmedlingsnod arkitektur. Resultaten kan konsolidera vägen mot full överensstämmelse med AUTOSAR. / Le développement de systèmes embarqués dans l’industrie automobile a atteint un niveau de complexité très élevé. D’où la nécessité de créer de nouvelles méthodologies. AUTomotive Open Architecture (AUTOSAR) a été créé pour la mise place de standards pour le développement dans l’industrie automobile. Dans l’architecture AUTOSAR, le développement de logiciels embarqués est reparti, en général, entre trois partis : Original Equipement Manufacturer (OEM), Renault par exemple. Le deuxième niveau regroupe les fournisseurs de logiciels et outils, par exemple, Elektrobit. On retrouve en troisième position les Tier-2 suppliers, fournisseurs de cartes électroniques pour l’automobile, comme Renesas ST. Le développement de calculateurs est séparé par domaine : Multimédia, châssis, motorisation et intérieur. La communication inter-domaine passe par un calculateur passerelle. Le calculateur passerelle est essentielle dans l’architecture électronique du véhicule. Dans AUTOSAR, le calculateur est fourni par un tiers parti, différent du constructeur automobile. Il est donc nécessaire pour le constructeur d’être capable de configurer le calculateur passerelle, sans repasser par le vendeur. Par exemple, le constructeur peut décider, réception du software de rajouter une nouvelle route dans la passerelle. Cet aspect est connu sur le nom de Post-build Configuration dans AUTOSAR. Le but de ce stage est le design et l’implémentation de Post-build configuration d’un calculateur passerelle. D’abord, AUTOSAR et l’architecture électronique d’un calculateur passerelle sont détaillées. Les protocoles de communication sont aussi décrits. Ensuite, le design et les choix d’implémentation sont discutés. L’implémentation est évaluée avec des tests de régression sur les fonctionnalités de routage. Aussi, la solution finale est évaluée sur les critères de performance de routage, l’efficacité en consommation mémoire et la capacité d’être intégrée dans un produit final.

[pt] A adaptação dinâmica de aplicações distribuídas tem se tornado um recurso cada vez mais essencial na construção de sistemas de computação. Isso é justificado especialmente pelo avanço da tecnologia, que tem permitido a automação de tarefas complexas em domínios de aplicação cada vez menos tolerantes à suspensão de serviços. Nesta dissertação é proposto o LuaOrb Adaptation Framework, que utiliza os recursos da linguagem Lua na adaptação dinâmica de sistemas baseados em componentes do Modelo de Componentes de CORBA (CCM - CORBA Component Model ). Através desse framework é possível utilizar as abstrações de papéis e protocolos para realizar adaptações criando novas interações entre os componentes do sistema, assim como reconfigurar dinamicamente os componentes CCM. Devido a limitações do modelo CCM, é proposta uma adaptação desse modelo para a linguagem Lua, de onde surge o conceito de contêiner dinâmico, que permite a construção de componentes dinamicamente adaptáveis através de alterações na estrutura e implementação desses componentes. O contêiner dinâmico permite que essas alterações sejam feitas em níveis diferentes, ou seja, no nível de uma única instância ou implementação de componente, assim como em todas as instâncias de um determinado componente. / [en] Dynamic adaptation of distributed applications has become an essential feature in development of computer systems, mainly justified by nowadays technology, which enables complex tasks to be performed by computers in application domains less suited for service interruption. This dissertation proposes the LuaOrb Adaptation Framework, which uses features of the programming language Lua to dynamically adapt systems based on the CORBA Component Model (CCM). This framework uses abstractions like roles and protocols to adapt systems by creating new interactions between systems components, as well as provides features for dynamic reconfigurations of CCM components. Due to limitations of CCM, an adaptation of this model to Lua concepts is proposed, resulting in the definition of dynamic containers, which enable development of dynamically adaptable components by changes on component structure and implementation. Dynamic containers allows adaptations to be done on different levels, namely on the level of a single component instance or implementation, as well as on all instances of a given component.