[ENG] Source by @alfonsoalfonsi made using CANVAS and image by PxHere
[SPA] Fuente por @alfonsoalfonsi realizado usando CANVAS e imagen de PxHere
Hello Hive Friends, continuing with theEmbedded System (ES) theme, I will present you the third part of this series, focused on the Software component, specifically the Embedded Software Architectures.
Hola Amigos de Hive, siguiendo con el tema de los Sistemas Empotrados o Embebidos (SE) les presentaré la tercera parte de esta serie, enfocada en el componente de Software, específicamente la Arquitecturas del Software Empotrado.
In previous posts on Embedded System with Style, the Part One: Concept and Context and Part Two: Architectural Style - Hardware important definitions and common thread of the Embedded Software component were established.
En post anteriores de Sistema Empotrado o Embebido con Estilo, la Primera Parte: Concepto y Contexto y la Segunda Parte: Estilo Arquitectónico – Hardware se establecieron definiciones importantes e hilo conductor del componente Software Empotrado.
In addition, two development directions were pointed out, one with low computational processing, and the other, where real-time operation facilities, energy adjustment management, high signal processing performance, etc., Conventional Embedded Software and Advanced, respectively, should be provided.
Además se señalaron dos vertientes de desarrollo, una con bajo procesamiento computacional, y otra, donde deben otorgarse facilidades de operación en tiempo real, manejo del ajuste de energías, altas prestaciones de procesamiento de señales, etc., Software Empotrado Convencional y Avanzado, respectivamente.
PRELIMINARY
PRELIMINARES
The basic phases for embedded software development are the Software Architecture, which is then documented and advanced until it becomes the final application of the system, which is why it is considered in the literature as a system design plan.
En las fases básicas para el desarrollo software empotrado se encuentra el diseño de la Arquitectura del Software, que luego va documentándose y avanzando hasta convertirse en la aplicación final del sistema, razón por la cual en la literatura es considerada como plan de diseño del sistema.
The architecture is preceded only by the system requirements, which form the basis for decisions about the overall architecture. And, such decisions, in turn, constrain the software architecture.
A la arquitectura solo le antecede los requisitos del sistema, que forman la base para las decisiones sobre la arquitectura general. Y, tales decisiones limitan a su vez la arquitectura del software.
Definition
Definición
ISO/IEC/IEEE 42010:2011 defines:
La norma ISO/IEC/IEEE 42010:2011 define:
Software architecture is the fundamental organization of a system formed by its components, the relationships between them and the context in which they will be implemented, and the principles that guide their design and evolution.
Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución.
That is, on the one hand, it defines the system structure, which is made up of components, modules or pieces of code that are born from the notion of abstraction, fulfilling specific functions, and interacting with each other with defined behavior.
Es decir, por un lado define la estructura del sistema, que está constituida de componentes, módulos o piezas de código que nacen de la noción de abstracción, cumpliendo funciones específicas, e interactuando entre sí con un comportamiento definido.
The components allow, at the design level, to make the necessary decisions during the construction of a software system.
Los componentes permiten, a nivel de diseño, tomar las decisiones necesarias durante la construcción de un sistema de software.
In addition, the choice of the appropriate architecture must provide the desired functionality and quality attributes. It is basically determined by quality criteria such as modifiability, maintainability, security, and performance.
Además, la elección de la arquitectura adecuada debe proporcionar la funcionalidad deseada y atributos de calidad. Es determinada básicamente por criterios de calidad como la modificabilidad, mantenibilidad, seguridad y el rendimiento.
A LOOK AT SYSTEM REQUIREMENTS
PINCELADA A LOS REQUERIMIENTOS DEL SISTEMA
In the literature on Software Engineering, authors such as Roger S. Pressman maintain that there are two kinds of models: requirements and design models.
En la literatura acerca de la Ingeniería de Software, autores como Roger S. Pressman mantienen que hay dos clases de modelos: de requerimientos y de diseño.
The former, represent customer requirements in three domains: information, functional and behavioral; design models are software features that help to effectively elaborate: architecture, user interface, and component-level detail (Pressman & Maxim, 2019).
Los primeros, representan los requerimientos del cliente en tres dominios: información, funcional y comportamiento; los modelos de diseño son características del software que ayudan a elaborar con eficacia: arquitectura, interfaz de usuario y detalle en el nivel de componente (Pressman y Maxim, 2019).
That is, many things must be specified and documented in a software project. There are functional and non-functional requirements. These aspects of information capture are taken care of by Requirements Engineering which is a branch of Software Engineering.
Es decir, muchas cosas se deben especificar y documentar en un proyecto software. Están, los requisitos funcionales y no funcionales. Estos aspectos de captura de información son atendidos por la Ingeniería de Requisitos que es una rama de la Ingeniería de Software.
In this post, I will not go deep into this topic because it is quite extensive and one should be careful when approaching it. However, good documentation can be found in several texts (Pressman & Maxim, 2019; Sommerville, 2018) or, in the standard ISO/IEC/IEEE 29148:2018.
En este post no voy a profundizar en este tópico, porque es bastante extenso y se debe ser cuidadoso al plantearlo. No obnstante, una buena documentación la pueden encontrar en varios textos (Pressman y Maxim, 2019; Sommerville, 2018) o, en la norma ISO/IEC/IEEE 29148:2018.
In ESs the above becomes more acute, because having restrictions of size, weight, energy autonomy, real-time, to name a few, the developer must be prepared to determine them. Be it for Conventional Embedded Software or Advanced, providing the desired functionality and quality attributes.
En los SE lo anterior se agudiza, porque al tener restricciones de tamaño, peso, autonomía energética, tiempo real, por nombrar algunas, el desarrollador debe prepararse para determinarlas. Sean para el Software Empotrado Convencional o Avanzado, proporcionando la funcionalidad deseada y atributos de calidad.
TAXONOMY
TAXONOMÍA
Here I will indicate the taxonomy of Architectural Style presented by Pressman (2010) which is taken to the ES.
Aquí indicaré la taxonomía del Estilo Arquitectónico que presenta Pressman (2010) el cual es llevado a los SE.
1. Data Centered.
1. Centrada en los Datos.
At the center of this architecture is a data storage that is frequently accessed by other components that update, add, delete or modify data in some way within the storage (Figure 1).
En el centro de esta arquitectura se halla un almacenamiento de datos al que acceden con frecuencia otros componentes que actualizan, agregan, eliminan o modifican los datos de cierto modo dentro del almacenamiento (Figura 1).
Figure 1. Data-Centred Architectural Style. Source: Pressman (2010, Chapter 9)
Figura 1. Estilo Arquitectónico Centrada en los datos. Fuente: Pressman (2010, Capítulo 9)
2. Data Flow.
2. De Flujo de Datos.
El sistema es visto como una serie de transformaciones a través de una serie de componentes computacionales o manipuladores El dato ingresa en el sistema, y fluye entre los componentes, de uno en uno, hasta que se le asigne un destino final (Figura 2).
Figure 2. Architectural style of data flow. Source: Pressman (2010, Chapter 9)
Figura 2. Estilo Arquitectónico de flujo de datos. Fuente: Pressman (2010, Capítulo 9)
3. Call and Return.
3. De Llamar y Regresar.
The system consists of the main program that has control of the system and several subprograms that communicate with it through the use of calls. Within this category, there are several sub-styles, such as Main Program/Sub-Program Architectures and Remote Procedure Call Architectures (Figure 3).
El sistema se constituye de un programa principal que tiene el control del sistema y varios subprogramas que se comunican con éste mediante el uso de llamadas. Dentro de esta categoría existen varios subestilos, como las Arquitecturas de programa principal/subprograma y Arquitecturas de llamada de procedimiento remoto (Figura 3).
Figure 3. The architectural style of call and return. Source: Pressman (2010, Chapter 9)
Figura 3. Estilo Arquitectónico de llamar y regresar. Fuente: Pressman (2010, Capítulo 9)
4. Object-Oriented Architectures.
4. Arquitecturas Orientadas a Objetos.
The components of a system include data and the operations that must be applied to manipulate them. Communication and coordination between the components are achieved through the transmission of messages.
Los componentes de un sistema incluyen datos y las operaciones que deben aplicarse para manipularlos. La comunicación y coordinación entre los componentes se consigue mediante la transmisión de mensajes.
5. Layered.
5. En capas.
In the basic structure of a layered architecture, several different layers are defined; each layer executes operations that progressively approximate the machine instruction set.
En la estructura básica de una arquitectura en capas, se define un número de capas diferentes; cada una ejecuta operaciones que se aproximan progresivamente al conjunto de instrucciones de máquina.
In the outer layer, components serve the user interface operations. At the internal layer, components interface with the operating system. The middle layers provide utility services and application software functions (Figure 4).
En la capa externa, los componentes atienden las operaciones de la interfaz de usuario. En la interna, los componentes realizan la interfaz con el sistema operativo. Las capas intermedias proveen servicios de utilerías y funciones de software de aplicación (Figura 4).
Figure 4. Layered Architectural Style. Source: Pressman (2010, Chapter 9)
Figura 4. Estilo Arquitectónico en capas. Fuente: Pressman (2010, Capítulo 9)
EXAMPLE
EJEMPLO
Purpose.
Planteamiento.
We want to design an ES based on Microcontroller, which measures two (2) magnitudes coming from two (2) temperature sensors. The values are averaged and the result is prepared for a communication link with a Desktop Computer, besides presenting the data of such activity is an indicator that has the ES. The information will contain Identification of the activity (1, 2, ..., N), Sensor 1 Temperature, Sensor 2 Temperature, Average Temperature obtained. In addition, there is a switch that activates or deactivates the system.
Se quiere diseñar un SE basado en Microcontrolador, que mide dos (2) magnitudes que provienen de dos (2) sensores de temperatura. Los valores son promediados y el resultado es preparado para un enlace de comunicación con un Computador de Escritorio, además de presentar los datos de dicha actividad en un indicador que posee el SE. La información contendrá: Identificación de la actividad (1, 2, …, N), Temperatura del Sensor 1, Temperatura del Sensor 2, Promedio de la Temperatura obtenida. Además, hay un interruptor que activa o desactiva el sistema.
For this purpose there is a Hypothetical Processor (HP) that has resources for digital and analog communication (I/O ports), I2C, communication port via USB, works at an operating frequency F MHz and is powered with a voltage level of V, it also has memory to house both embedded program code, interrupt handling and any other basic facilities of this type of device.
Para tal fin se tiene un Procedor Hipotético (PH) que posee recursos para la comunicación digital y analógica (Puertos I/O), (I2C), puerto de comunicación vía USB, trabaja a una frecuencia de operación F MHz y está alimentado con un nivel de voltaje de V, además tiene memoria para alojar tanto el código del programa empotrado, manejo de interrupciones y cualquier otra facilidad básica de este tipo de dispositivo.
It is worth noting that here we will not analyze the Hardware and Software Architectures that give a feasible and achievable solution to the problem. For this, it is necessary to survey their requirements. We will only discuss the different alternatives of the solution, highlighting some of its characteristics.
Vale la pena destacar, que aquí no se analizarán las Arquitecturas de Hardware y Software que dan una solución factible y realizable al problema. Para esto hay que hacer un levantamiento de sus requerimientos. Solo discutiremos las diferentes alternativas de la solución, destacando algunas de sus características.
Traditional Hardware and Call and Return Software Architecture
Arquitectura de Hardware Tradicional y de Software de Llamar y Regresar
From the approach, the Traditional Hardware Architecture for the Example is presented (Figure 5), where the HP resources are leveraged to satisfy the approach.
Del planteamiento se presenta la Arquitectura de Hardware Tradicional para el Ejemplo (Figura 5), donde se aprovecha los recursos del PH para satisfacer el planteamiento.
Figure 5. Traditional Hardware Architecture of the Example System.
Figura 5. Arquitectura de Hardware Tradicional del Sistema Ejemplo.
Then:
Entonces:
Now, the specifications for the Call and Return Software Architecture must be created (Figure 6).
Ahora, se debe crear las especificaciones para la Arquitectura de Software de Llamar y Regresar (Figura 6).
Figure 6. Example System Call and Return Software Architecture.
Figura 6. Arquitectura de Software de Llamada y Regresar del Sistema Ejemplo.
For this purpose, the basic requirements are:
Para ello, los requerimientos básicos son:
Actually, other connections could be made in the modules indicated in the architecture, so it is not the only solution. This then becomes a function-based code, which is common among programmers.
Realmente, se podría hacer otras conexiones en los módulos señalados en la arquitectura, por tanto no es la única solución. Esto luego se transforma en un código basado en funciones, lo cual es común entre programadores.
Traditional Hardware and Object-Oriented Software Architecture.
Arquitectura de Hardware Tradicional y de Software Orientada a Objetos.
An Object Oriented Software Architecture can be proposed. Of course, for this, everything concerning object-orientation must be understood and handled. Nowadays, microcontrollers and their software facilities help a lot to establish this kind of architecture.
Se puede proponer una Arquitectura de Software Orientada a Objetos. Por supuesto que para ello se debe entender y manejar todo lo concerniente a la orientación objeto. En la actualidad, los microcontroladores y sus facilidades de software ayudan mucho a establecer este tipo de arquitecturas.
Of course, a simple example is taken here for exemplification and I use a notation employed in this context called Unified Modeling Language (UML) (Pressman & Maxim, 2019; Sommerville, 2018).
Por supuesto, aquí se toma un ejemplo sencillo para ejemplificar y utilizo una notación empleada en este contexto llamada Lenguaje Unificado de Modelado (UML: Unified Modeling Language) (Pressman & Maxim, 2019; Sommerville, 2018).
Figure 7 depicts the Example General Use Case Diagram to express the behavior of the system. These diagrams model system functionality using actors and use cases. Use cases are services or functions provided by the system for its users.
En la Figura 7 se representa el Diagrama de Caso Uso General del Ejemplo para expresar el comportamiento del sistema. Estos diagramas modelan la funcionalidad del sistema usando actores y casos de uso. Los casos de uso son servicios o funciones provistas por el sistema para sus usuarios.
Figure 7. Object-Oriented Software Architecture. General Use Case of the Example.
Figura 7. Arquitectura de Software Orientada a Objetos. Caso de Uso General del Ejemplo.
The General Use Case Diagram of the Example highlights the behavior of the system, where Actors such as the Operator that manages the system and Personal Computer to which the information generated by the system is sent, have roles and characteristics that must be written in detail.
En el Diagrama de Caso Uso General del Ejemplo se destaca el comportamiento del sistema, donde Actores como el Operador que maneja el sistema y Computador Personal al cual se le envía la información generada por el sistema, tiene roles y características que se deben escribir en detalle.
Likewise, there are the Indicator, the output device that consumes the information generated by the system, and Temperature Sensors that represent the transducers that feed the data to the system.
Así mismo, está el Indicador, dispositivo de salida que consume la información generada por el sistema, y Sensores de Temperatura que representa los transductores que alimentan los datos al sistema.
Three (3) use cases are also indicated, which can be detailed to meet the specifications of the system, being these:
También se indican tres (3) casos de uso, los cuales pueden ser detallados para llegar a cumplir las especificaciones del sistema, siendo estos:
It is worth noting that the modeling is done through several diagrams that visually show the characteristics of the embedded software. Together they form the Software Architecture.
Vale la pena destacar que el modelado se realiza a través de varios diagramas que muestran visualmente características del software empotrado. En su conjunto forman la Arquitectura de Software.
For example, using the UML, you will find two subsets called structural and behavioral diagrams, each with its own function, which together allow the understanding of the system software as a whole.
Por ejemplo utilizando el UML, se encontrarán dos subconjuntos llamados diagramas estructurales y de comportamiento, cada uno con su propia función, que en conjunto permiten la comprensión del software del sistema como un todo.
A comparison of why to use several views to express a system is a building, it is not possible to elaborate a single plan containing all the details, several are elaborated to represent the different aspects.
Una comparación del por qué usar varias vistas para expresar un sistema es una edificación, no es posible elaborar un solo plano que contenga todos los detalles, se elaboran varios que representan los diferentes aspectos.
At this point, it would be worth asking the question: if I opt for another Hardware Architecture, how would the Software Architecture look like, could I use the diagram in Figure 7 in another architecture? A good exercise.
En este punto, valdría la pena preguntarse ¿si opto por otra Arquitectura de Hardware, cómo quedaría la de Software?, ¿podría usar el diagrama de la figura 7 en otra arquitectura? Un buen ejercicio.
EMBEDDED SOFTWARE COMPONENT
COMPONENTE DE SOFTWARE EMPOTRADO
While it is true that in the software architecture the respective models of what will be the system are made, its implementation is another matter. Therefore, the original concept of Software Architecture lies in Architectural Design.
Si bien es cierto, que en la arquitectura de software se hacen los respectivos modelos de lo que será el sistema, su implementación es otro asunto. Por tanto, el concepto original de la Arquitectura de Software recae en el Diseño Arquitectónico.
Reflecting the above in Figure 8, the Architecture is the basis for the Firmware and the Application since the design and implementation will follow what is detailed in it. When in an ES there is the possibility of having an Operating System, this will be part of the facilities and resources available to the system, even if it is a micro or nanocore.
Reflejando lo anterior en la Figura 8, la Arquitectura es la base para el Firmware y la Aplicación ya que el diseño e implementación seguirá lo detallado en esta. Cuando en un SE hay la posibilidad de tener un Sistema Operativo pues este formará parte de las facilidades y recursos con que cuenta el sistema, aun cuando sea un micronúcleo o nanonúcleo.
Figure 8. Embedded Software Component. Source: @alfonsoalfonsi
Figura 8. Componente de Software Empotrado. Fuente: @alfonsoalfonsi
Cada vez más, hay SE que alojan Sistemas Operativos con muy buenas prestaciones. El Teléfono Inteligente es un buen ejemplo de ello.
Currently, SE Architectures are incorporating methodologies, technologies, and standards that enthusiasts in this field should always consult. Therefore, I point you to Taylor and Taylor (2021), Voigtmann GmbH (2021), and Lacamare (2018) among some references that might be useful to keep you up to date.
Actualmente, las Arquitecturas de los SE van incorporando metodologías, tecnologías y normas que los entusiastas de este campo siempre deben consultar. Por tanto, les indico a Taylor y Taylor (2021), Voigtmann GmbH (2021) y Lacamare (2018) entre algunas referencias que pudieran servirles para mantenerse al día.
CLOSING PART THREE
CIERRE DE LA TERCERA PARTE
The Embedded Software Architecture is documented and advanced until it becomes the final application of the system, which is why it is considered in the literature as a system design plan.
La Arquitectura del Software Empotrado va documentándose y avanzando hasta convertirse en la aplicación final del sistema, razón por la cual en la literatura es considerada como plan de diseño del sistema.
The architecture is preceded only by the system requirements, which form the basis for decisions about the overall architecture. And, such decisions, in turn, constrain the software architecture. In addition, the choice of the appropriate architecture must provide the desired functionality and quality attributes.
A la arquitectura solo le antecede los requisitos del sistema, que forman la base para las decisiones sobre la arquitectura general. Y, tales decisiones limitan a su vez la arquitectura del software. Además, la elección de la arquitectura adecuada debe proporcionar la funcionalidad deseada y atributos de calidad.
Therefore, I invite ES developers to use all the tools and facilities provided by current technologies.
Por tanto, aquellos desarrolladores de SE les invito a utilizar todas las herramientas y facilidades que nos otorgan las tecnologías actuales.
See you soon HIVE friends, I hope you liked this post.
Nos vemos pronto amigos HIVE, espero que les haya gustado este post.
Thank you for your time and comments.
Gracias por su tiempo y comentarios.
REFERENCES / REFERENCIAS
Alfonsi, A. [@alfonsoalfonsi] (2021, June 4). [Eng-Spa] Embedded Systems with Style. Part Two: Arquitectonic Style-Hardware. The HiVE Blog. [POST]. https:// @alfonsoalfonsi/eng-spa-embedded-system-with-style-part-two-architectural-style-hardware-sistema-empotrado-o-embebido-con-estilo-segunda-parte
Alfonsi, A. [@alfonsoalfonsi] (2021, May 29). [Eng-Spa] Embedded Systems with Style. Part One: Concept and Context. The HiVE Blog. [POST]. @alfonsoalfonsi/eng-spa-sistema-empotrado-o-embebido-con-estilo-primera-parte-concepto-y-contexto-embedded-system-with-style-part-one-concept
ISO/IEC/IEEE (2011). ISO/IEC/IEEE 42010:2011 - ISO/IEC/IEEE Systems and Software Engineering - Architecture Description. https://www.iso.org/standard/50508.html
ISO/IEC/IEEE (2018). ISO/IEC/IEEE 29148:2018. Systems and software engineering-Life cycle processes -- Requirements engineering. https://www.iso.org/standard/72089.html
Lacamare, D. (2018). Embedded Systems Architecture: Explore architectural concepts, pragmatic design patterns, and best practices to produce robust systems. Packt Publishing.
Pressman, R. S. & Maxim, B. R. (2019). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill Education.
Pressman, R. S. (2010). Software Engineering: A Practitioner's Approach (7th ed.). McGraw-Hill Higher Education.
Pressman, R. S. (2010). Ingeniería de Software:Un Enfoque Práctico (7a ed.). McGraw-Hill Interamericana Editores S.A. de C.V.
Sommerville, I. (2018). Software Engineering (10a ed.). Pearson India.
Taylor, J. T. & Taylor, W. T. (2021). Patterns in the Machine: A Software Engineering Guide to Embedded Development. Apress.
Voigtmann GmbH. (2021). Software architecture. Consultado el 28 de octubre de 2019.
https://www.voigtmann.de/en/app-development/software-architecture/
Figures/ Figuras
Figures 1, 2, 3, and 4 are from Pressman's book (2010, Chapter 9) and were adjusted using Paint.
Figures 5, 6, 7, and 8 are my own and were made using Power Point and Paint.
Las Figuras 1, 2, 3, 4 son del libro de Pressman (2010, Capítulo 9) y fueron ajustadas usando Paint.
Las Figuras 5, 6 7 y 8 son de mi propiedadfueron realizadas usando Power Point y Paint.
[ENG] The banner and the photographs on it are my property. Made with Power Point, Paint and the Linerock Investment LTD ToonMe App.
[SPN]El banner y las fotografías son de mi propiedad. Realizado con Power Point, Paint y Linerock Investment LTD Aplicación ToonMe.