Evaluation of (De-)Centralized IT technologies in the fields of Cyber-Physical Production Systems

In the course of the digital transformation, organizations are not only facing increasing volatility of the markets, but also increasing customer requirements and thus an increasing complexity in production and logistics systems. Therefore, production plants need to become more flexible by transforming conventional production systems to Cyber-physical Production Systems (CPPS). CPPS allow organizations to dynamically react to fluctuations in demand and markets and to introduce new product lines quickly and effectively. The challenge in implementing CPPS is to handle and store relevant data streams between Cyber-physical objects in a secure but transparent way. As CPPS involve a high level of decentralization, the data storage can either be combined with centralized IT-solutions like a Cloud or utilize decentralized IT-technologies like Edge Computing or Distributed Ledger Technologies (DLT) like Blockchains. The paper addresses the suitability of centralized and decentralized technologies in terms of dealing with data streams in the fields of CPPS. For this purpose, based on a paper exploration, appropriate evaluation criteria are derived, followed by a comparison of exemplary centralized and decentralized technologies. The outcome is a qualitative evaluation of the supplement of each technology regarding its suitability of dealing with data streams

Gestion autonomique d'applications dynamiques sûres et résilientes

Service-Oriented architectures (SOA) are considered the most advanced way to develop and integrate modular and flexible applications.There are many SOA platforms available for software developers and architects; the most evolved of them being SCA and OSGi.An application based on one of these platforms can be assembled with only the components required for the execution of its tasks, which helps decreasing its resource consumption and increasing its maintainability.Furthermore, those platforms allow adding plug-ins at runtime, even if they were not known during the early stages of the development of the application.Thus, they allow updating, extending and adapting the features of the base product or of the technical services required for its execution, continuously and without outage.Those capabilities are applied in the DevOps paradigm and, more generally, to implement the continuous deployment of artifacts.However, the extensibility provided by those platforms can decrease the overall reliability of the system: a strong tendency in software development is the assembly of third-parties components.Such components may be of unknown or even questionable quality.In case of error, deterioration of performance, ... it is difficult to identify the implicated components or combinations of components.It becomes essential for the software producer to determine the responsibility of the various components involved in a malfunction.This thesis aims to provide a platform, Cohorte, to design and implement scalable software products, resilient to malfunctions of unqualified extensions.The components of such products may be developed in various programming languages and be deployed continuously (adding, updating and withdrawal) and without interruption of service.Our proposal adopts the principle of isolating the components considered unstable or insecure.The choice of the components to be isolated may be decided by the development team and the operational team, from their expertise, or determined from a combination of indicators.The latters evolve over time to reflect the reliability of components.For example, components can be considered reliable after a quarantine period; an update may result in deterioration of stability, ...Therefore, it is essential to question the initial choices in isolating components to limit, in the first case, the scope of communications between components and, in the second case, to maintain the reliability of the critical core of the product.Les architectures orientées services (SOA) sont considérées comme le moyen le plus avancé pour réaliser et intégrer rapidement des applications modulaires et flexibles.Dans ce domaine, les plates-formes SOA à disposition des développeurs et des architectes de produits logiciels sont multiples; les deux plus évoluées d'entre elles étant SCA et OSGi.Une application s'appuyant sur l'une de ces plates-formes peut ainsi être assemblée avec le minimum de composants nécessaires à la réalisation de ses tâches, afin de réduire sa consommation de ressources et d'augmenter sa maintenabilité.De plus, ces plates-formes autorisent l'ajout de composants greffons qui n'étaient pas connus lors des phases initiales de la réalisation du produit.Elles permettent ainsi de mettre à jour, d'étendre et d'adapter continuellement les fonctionnalités du produit de base ou des services techniques nécessaires à sa mise en production, sans interruption de service.Ces capacités sont notamment utilisées dans le cadre du paradigme DevOps et, plus généralement, pour mettre en œuvre le déploiement continu d'artefacts.Cependant, l'extensibilité offerte par ces plates-formes peut diminuer la fiabilité globale du système: une tendance forte pour développer un produit est l'assemblage de composants provenant de tierces-parties. De tels composants peuvent être d'une qualité inconnue voire douteuse.En cas d'erreur, de détérioration des performances, etc., il est difficile de diagnostiquer les composants ou combinaisons de composants incriminés.Il devient indispensable pour le producteur d'un logiciel de déterminer la responsabilité des différents composants impliqués dans un dysfonctionnement.Cette thèse a pour objectif de fournir une plate-forme, Cohorte, permettant de concevoir et d'exécuter des produits logiciels extensibles et résilients aux dysfonctionnements d'extensions non qualifiées.Les composants de tels produits pourront être développés dans différents langages de programmation et être déployés (ajout, mise à jour et retrait) en continu et sans interruption de service.Notre proposition adopte pour principe d'isoler les composants considérés comme instables ou peu sûrs.Le choix des composants à isoler peut être décidé par l'équipe de développement et l'équipe opérationnelle, à partir de leur expertise, ou bien déterminé à partir d'une combinaison d'indicateurs.Ces derniers évoluent au cours du temps pour refléter la fiabilité des composants.Par exemple, des composants peuvent être considérés fiables après une période de quarantaine; une mise à jour peut entraîner la dégradation de leur stabilité, etc..Par conséquent, il est indispensable de remettre en cause les choix initiaux dans l'isolation des composants afin, dans le premier cas, de limiter le coup des communications entre composants et, dans le deuxième cas, de maintenir le niveau de fiabilité du noyau critique du produit