Hardware, sistema operativo, aplicación, proceso y servicio
Este capítulo construye un mapa de ejecución para quien empieza desde cero. La pregunta rectora no es qué producto usa una persona, sino qué entidad hace qué trabajo y qué evidencia permite distinguir una capa de otra. El mapa recorre dispositivo físico, firmware, sistema operativo, programa instalado, proceso en ejecución y servicio ofrecido. Cada capa tiene una función, un estado y una frontera. Ninguna palabra sirve como atajo para todas las demás.
Un dispositivo físico reúne memoria, almacenamiento, pantalla, sensores y enlaces. El firmware es software persistente que participa en el arranque y la configuración inicial. El sistema operativo organiza recursos y ofrece un entorno para programas. Una aplicación instalada es un conjunto persistente de archivos y datos. Un proceso es una instancia activa con estado. Un servicio es una capacidad ofrecida a otro componente; puede ser local o remoto. Esta secuencia es un mapa conceptual, no una afirmación de que todos los sistemas tengan la misma implementación.
El mapa de capas
El dispositivo físico ofrece soporte material. El firmware participa en el arranque y deja una configuración utilizable. El sistema operativo organiza recursos y expone un entorno. El programa instalado permanece como archivos y datos. El proceso es una instancia temporal con estado. El servicio ofrece una función a otro componente. Las flechas entre capas expresan relación, nunca equivalencia.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Hardware y observación
Una pantalla, un botón, un sensor y una interfaz de red pertenecen al soporte físico, pero la observación de una señal no identifica por sí sola el programa que la interpretó. Describir el dispositivo exige indicar qué entrada recibió, en qué intervalo y qué componente la convirtió en estado. Así se evita atribuir intención al hardware.
Firmware y arranque
El firmware ocupa una posición de preparación. Puede seleccionar un medio de arranque y reconocer componentes, pero no debe confundirse con la aplicación que usa la persona. Para una afirmación sobre firmware se necesita evidencia de la versión, el momento y la función examinada; el resto queda fuera del mapa.
Sistema operativo y recursos
El sistema operativo administra recursos y permite que varios programas coexistan. Que controle una pantalla o una conexión no significa que determine el significado de cada aplicación. Un modelo correcto conserva la relación de administración sin convertirla en autoría de todas las acciones.
Programa instalado y persistencia
La presencia de un archivo o paquete demuestra almacenamiento bajo ciertas condiciones. No demuestra que el programa esté abierto, que una tarea se haya ejecutado o que un servicio remoto haya recibido información. El claim debe conservar la diferencia entre existir y actuar.
Proceso y estado
Un proceso es una instancia activa, con estado y duración. Dos instancias del mismo programa pueden tener propósitos o estados diferentes. Una lista de procesos es una observación situada: sirve para hablar de ese instante y ese sistema, no para afirmar una actividad histórica completa.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Multiplicidad
Una aplicación puede separar interfaz, sincronización y notificación en procesos distintos. La separación permite que uno termine mientras otro continúa. Por eso «la aplicación hizo» es una abreviatura que debe expandirse cuando la pregunta depende del productor exacto.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Servicio local
Un servicio puede ser una capacidad ofrecida dentro del mismo dispositivo. El término describe la relación entre quien solicita y quien responde. No exige una red ni una máquina separada. Esta precisión evita llamar remoto a todo servicio o asumir que todo proceso ofrece una interfaz pública.
Servicio remoto
Cuando la función se ofrece fuera de la frontera local, el proceso cliente prepara una petición y recibe una respuesta. Cliente y servidor son roles de esa interacción. La respuesta observada no prueba por sí sola persistencia, disponibilidad futura, retención o lectura humana.
Fronteras
Una frontera decide qué entidades y estados entran en la pregunta. Para estudiar una pantalla basta quizá el proceso local; para estudiar una función remota hay que incluir la ruta y el servicio. Ampliar la frontera añade dependencias y supuestos, no certeza automática.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Caso de impresión
Una solicitud de impresión puede pasar de entrada física a programa instalado, proceso, cola y función ofrecida por una impresora. «Enviando» sólo describe una representación. Para afirmar que salió una página hay que observar otra capa, con su propio productor y sus condiciones.
Caso de cámara
Una cámara detecta luz, crea datos y puede sincronizar una copia. «Grabando» puede indicar una señal local sin demostrar que existe una copia consultable remotamente. El mapa obliga a separar sensor, almacenamiento, proceso de captura, proceso de sincronización y servicio de consulta.
Claims acotados
Un claim útil especifica sistema, capa, condición, intervalo y evidencia. «El proceso de captura permaneció activo durante la prueba» es revisable. «El dispositivo funciona» no identifica propiedad ni horizonte. La precisión no reduce el valor: hace posible la revisión.
Predicción y revisión
Cada capa permite una predicción. Si existe un proceso activo, esperamos una señal de ejecución; si una petición fue aceptada, esperamos una respuesta definida por el contrato. Cuando la predicción falla, se revisa el supuesto, el contexto o la frontera sin borrar la observación.
Límites
Este capítulo no desarrolla kernel, llamadas al sistema, privilegios, aislamiento ni protocolos avanzados. Esos temas requieren modelos posteriores. Aquí se aprende a separar entidades y a reconocer cuándo una conclusión cruza una frontera sin evidencia.
Cierre
El mapa completo permite responder tres preguntas: qué existe, qué está ejecutándose y qué función se ofrece. También permite decir qué no se sabe. Esa combinación de capas, relaciones, estados y límites prepara el estudio posterior sin convertir una etiqueta en garantía.
Fuentes principales
- NIST CSRC Glossary — vocabulario de hardware, firmware, proceso y servicio.
- NIST SP 800-160 Vol. 1 Rev. 1 — sistemas y elementos.
- POSIX Base Definitions — proceso y ejecución.
- RFC 9110 — roles de interacción.
Preguntas de diagnóstico por capa
Arranque y continuidad
En el arranque, una observación del firmware no permite inferir qué programa se ejecutará después; registra versión y dispositivo.
Interfaces y productores
En una carga de programa, el archivo permanece en almacenamiento mientras el cargador crea una instancia temporal; compara ambos estados.
Colas y espera
En una interfaz detenida, la ausencia de proceso no demuestra que el archivo haya desaparecido; consulta persistencia y ejecución por separado.
Finalización limpia
En una aplicación con tareas concurrentes, identifica qué instancia produjo cada salida y qué estado compartía realmente.
Reinicio del dispositivo
En una cola local, una petición pendiente no prueba aceptación remota; busca la respuesta del servicio y su intervalo.
Observación temporal
En una respuesta remota, distingue recepción, procesamiento y persistencia; una marca no cubre todas las transiciones.
Evidencia negativa
En una consulta de cámara, separa sensor, proceso de captura, proceso de sincronización y servicio de consulta.
Alcance de una fuente
En una impresora, separa orden local, cola, dispositivo físico y resultado material antes de afirmar finalización.
Comparar implementaciones
En una comparación de implementaciones, conserva relaciones pero no inventes que dos nombres designan el mismo proceso.
Resumen transferible
En una conclusión final, escribe productor, estado, evidencia y límite; si falta uno, reduce el alcance del claim.
Diagnóstico de una pausa
Cuando una operación parece detenida, empieza por el soporte físico y avanza sólo hasta la capa que la evidencia permite. Comprueba si el dispositivo recibió entrada, si el firmware dejó el componente disponible, si el sistema operativo reconoce el programa, si existe una instancia activa y si la función ofrecida respondió. Este orden evita saltar directamente a una causa remota y hace visible qué observación falta.
Diferencia entre cargar y ejecutar
Cargar un programa desde almacenamiento crea las condiciones para una ejecución, pero no prueba que la instancia haya alcanzado el punto que interesa. Una revisión situada anota el archivo, la acción de carga, el estado del proceso y el resultado producido. Si el archivo cambia mientras una instancia existe, las dos entidades conservan historias diferentes. Esta distinción es útil al comparar instalaciones, reinicios y fallos.
Cooperación entre procesos
La separación en procesos puede servir para aislar tareas de interfaz, sincronización y notificación sin convertirlas en mecanismos idénticos. Para reconstruir una salida hay que identificar qué instancia la produjo y qué datos recibió. Un proceso que espera una cola no tiene el mismo estado que otro que consume esa cola. La palabra aplicación sólo resume el conjunto; el análisis necesita instancias y relaciones.
Servicio y contrato observable
Un servicio se reconoce por una capacidad ofrecida y por el contrato de la interacción, no por una etiqueta de servidor. La respuesta puede indicar aceptación de una solicitud sin demostrar que el resultado durará o será visible desde toda consulta. Al estudiar un servicio remoto, separa petición, recepción, procesamiento, persistencia y consulta. Cada transición puede tener otro productor y otra ventana temporal.
Prueba de frontera
Para saber si una afirmación cruza la frontera local, busca una observación cuyo productor esté fuera del dispositivo. Una pantalla local sólo prueba que un proceso local la mostró. Un registro del servicio, una respuesta documentada o una consulta controlada pueden aportar otra capa, pero también tienen contexto y límites. Si no se conoce el productor, la conclusión debe permanecer local y explícitamente incompleta.
Comparación de estados
El mismo nombre de estado puede ocultar estados diferentes en capas distintas. «Activo» puede describir un proceso, una conexión o una función ofrecida. El análisis escribe el sujeto y el intervalo: proceso activo durante la observación, petición pendiente en una cola, respuesta recibida en un momento y servicio disponible bajo una condición. Así se evita tratar estados parecidos como equivalentes.
Transferencia sin copiar
Al pasar el mapa a una cámara, impresora o reproductor, se conserva la estructura pero se reconstruyen los componentes. Un sensor no ocupa exactamente el papel de un archivo; una página impresa no es una respuesta de red; una reproducción local no demuestra catálogo remoto. La transferencia es correcta cuando identifica qué relación se mantiene y qué mecanismo cambia. Copiar nombres sin esas diferencias produce falsas analogías.
Criterio de cierre
Una explicación puede cerrarse cuando responde la pregunta declarada con evidencia proporcional y enumera lo que queda fuera. No hace falta descubrir toda la arquitectura para afirmar que un proceso produjo una salida local. Sí hace falta evidencia adicional para afirmar una decisión remota, persistencia, disponibilidad o intervención humana. El cierre de un claim es por alcance, no por sensación de completitud.
Qué hacer con una contradicción
Si una instancia aparece en una lista pero no produce la salida esperada, no elijas de inmediato entre «el proceso falló» y «el servicio falló». Comprueba primero que la lista, la salida y la petición pertenecen al mismo dispositivo, cuenta, intervalo y contexto. Después formula predicciones rivales: una ejecución local ausente debería cambiar la observación del proceso; una respuesta remota ausente debería conservar evidencia de la petición; una consulta en otro contexto debería mostrar una diferencia reproducible. Si ninguna prueba separa las hipótesis, la conclusión queda no determinada.
Preparar una descripción reproducible
Una descripción útil permite que otra persona reconstruya la misma frontera. Escribe el tipo de dispositivo, la versión pertinente, el programa instalado, el proceso observado, la función solicitada, el momento y el artefacto que respalda cada transición. Declara también qué no se inspeccionó: firmware, almacenamiento, proceso paralelo, servicio remoto o estado humano. Esta lista no es burocracia; evita que una inferencia se convierta en un hecho al pasar de una conversación a otra y conserva el alcance exacto del mapa.
Una matriz mental de evidencia por capa
Ante cualquier artefacto, formula dos preguntas: qué capa pudo producirlo y qué afirmación no sostiene. Una etiqueta en pantalla puede apoyar que el proceso de interfaz representó cierto estado, pero no que el archivo instalado tenga una versión concreta ni que el servicio remoto conservara datos. La presencia de un archivo puede apoyar instalación o persistencia, pero no actividad. Una instantánea de procesos puede apoyar existencia durante un intervalo, pero no demuestra qué ocurrió antes ni qué resultado produjo después.
El hardware ofrece otro tipo de evidencia. Una señal física confirma que algún circuito o componente produjo una salida bajo ciertas condiciones. No identifica automáticamente la instrucción, el proceso o la intención que la originó. Un dispositivo encendido puede no haber completado el arranque. Una interfaz de red activa puede no transportar la interacción que interesa. El modelo necesita conectar señal y productor mediante una relación documentada u observada.
La evidencia sobre firmware también requiere contexto. Una cadena de versión almacenada no demuestra necesariamente qué imagen participó en un arranque concreto. Una pantalla de configuración puede mostrar un estado de plataforma, pero no todas las decisiones posteriores del sistema operativo. Para un claim N0–N1 basta mantener la pregunta: ¿observé una imagen persistente, una fase de arranque o una configuración expuesta? Los detalles de verificación y confianza se estudiarán después.
En el sistema operativo, una observación puede mostrar que existe un recurso, que una instancia fue creada o que una operación fue solicitada. El sistema operativo media muchas relaciones, pero no absorbe la semántica de cada programa. Ver una conexión no explica por sí solo qué mensaje viajó; ver un proceso no explica qué función completó. La atribución profesional conserva identificador, tiempo y método.
En la capa de programa, el artefacto principal suele ser persistente: archivos, paquete, versión o configuración. En la capa de proceso, el artefacto es temporal: identificador, estado, salida o relación con otras instancias. Confundirlos produce diagnósticos falsos. Reinstalar archivos puede no afectar una instancia ya cargada; terminar una instancia puede no eliminar el programa ni su configuración. Cada intervención debe declarar cuál de las dos entidades pretende cambiar.
Finalmente, una respuesta de servicio sostiene una interacción concreta según su contrato. No convierte una capacidad temporal en disponibilidad futura, ni aceptación en persistencia, ni respuesta en efecto físico. Para ampliar el claim se necesita una nueva observación: consulta posterior, confirmación del productor apropiado o evidencia del resultado. Esta matriz no es una tabla para memorizar; es una disciplina para detener inferencias justo donde termina su procedencia.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Caso integrado: del clic a la hoja impresa
Una orden de impresión permite recorrer las capas sin hacerlas equivalentes. La persona pulsa imprimir mediante un dispositivo físico. Esa entrada llega a un programa instalado que presenta la interfaz, pero la interfaz visible no es necesariamente la entidad que conserva el trabajo. Una instancia de proceso construye datos de impresión y solicita recursos al sistema operativo. Una cola o servicio local puede aceptar el trabajo. Después, otra interacción lo entrega al dispositivo físico que produce la hoja.
El firmware participa en preparar los componentes durante el arranque, pero no conviene atribuirle cada decisión posterior. Del mismo modo, decir que el sistema operativo «imprime» resume varias relaciones: administra recursos, expone dispositivos y permite que procesos intercambien datos. El programa instalado aporta archivos persistentes; la instancia activa aporta un estado temporal. El servicio ofrece una capacidad. La impresora realiza un efecto físico. Una frase informal reúne todo; el modelo técnico lo separa para responder preguntas.
Supón que la pantalla muestra «trabajo enviado» y no aparece una hoja. Al menos cuatro hipótesis siguen abiertas. El proceso pudo producir sólo una etiqueta local; la cola pudo aceptar sin transferir; el servicio pudo transferir a otro destino; o la impresora pudo recibir y detenerse por una condición física. Cada hipótesis predice otra observación. Ver una instancia activa ayuda a estudiar ejecución, pero no prueba aceptación. Ver el trabajo en cola ayuda a estudiar estado local, pero no prueba recepción física. Una confirmación del dispositivo se acerca más al efecto, aunque todavía debe conocerse su semántica.
La misma secuencia muestra por qué «reiniciar la aplicación» es ambiguo. Cerrar una ventana puede terminar el proceso de interfaz y dejar activo un proceso auxiliar o un servicio local. Reiniciar el proceso no reinicia necesariamente el sistema operativo. Reiniciar el sistema operativo produce otra transición y puede no cortar alimentación a todos los componentes del dispositivo. Una instrucción de diagnóstico debe nombrar exactamente qué entidad se detiene, qué estado se pierde y qué evidencia se espera después.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Caso integrado: cámara con captura y sincronización
Una cámara doméstica añade una frontera remota. El sensor y el almacenamiento son hardware; firmware y sistema operativo preparan y administran recursos; el programa instalado contiene la lógica persistente; un proceso puede capturar; otro puede sincronizar; y un servicio puede ofrecer consulta desde otro dispositivo. La etiqueta «grabando» suele provenir de una capa local. No demuestra por sí sola que el proceso de sincronización esté activo, que el servicio haya aceptado el clip ni que una cuenta pueda consultarlo.
Si la grabación aparece localmente pero no en otra aplicación, hay que separar persistencia, sincronización, autorización y consulta. Este capítulo sólo resuelve las tres primeras como mapa de capas; los mecanismos de identidad y permiso vendrán después. La conclusión provisional puede ser: «el proceso local produjo una representación y existe una copia consultable en el dispositivo; la transferencia remota permanece no determinada». Es una conclusión útil porque delimita exactamente la siguiente pregunta.
También debe distinguirse el programa instalado de sus instancias. Una actualización puede cambiar archivos mientras una instancia anterior sigue activa o hasta que se reinicie. Por eso comprobar sólo la versión del paquete no basta para afirmar qué código produjo una salida en un intervalo. En este nivel no explicamos cargadores ni memoria; basta conservar dos entidades y buscar evidencia que las relacione.
Tres reconstrucciones que parecen iguales y no lo son
Primera: «la aplicación estaba abierta». La pantalla puede sostener que una interfaz fue visible, pero no identifica todos los procesos ni su historia. Segunda: «el servicio funcionó». Una respuesta sostiene una interacción concreta, no disponibilidad continua ni persistencia. Tercera: «el dispositivo estaba encendido». Una señal física no prueba que firmware, sistema operativo y programa alcanzaran estados utilizables. Las tres frases pueden ser apropiadas en conversación; ninguna basta como claim profesional sin productor, intervalo y propiedad.
La reconstrucción correcta empieza por el artefacto. Una señal luminosa pertenece al dispositivo. Una versión de firmware pertenece a una imagen o estado de plataforma. Una lista de procesos pertenece a una instantánea del sistema operativo. Un archivo pertenece al almacenamiento. Una respuesta pertenece a una interacción. Una hoja pertenece al efecto físico. Después se declara la inferencia necesaria para conectar artefactos. Si la inferencia cruza capa o frontera, se exige evidencia adicional.
Lo que ya puedes explicar
Ya puedes distinguir existencia física, preparación de plataforma, administración de recursos, persistencia de un programa, ejecución de una instancia y oferta de una función. Puedes explicar por qué un archivo no demuestra un proceso, por qué varios procesos pueden pertenecer a la misma aplicación y por qué servicio no significa automáticamente máquina remota. También puedes escribir una secuencia con productores y puntos de fallo sin convertir una interfaz en observación total.
Lo que todavía no estamos afirmando
Todavía no estudiamos kernel, llamadas al sistema, planificación, memoria virtual, aislamiento, privilegios, IPC detallado ni protocolos concretos de descubrimiento y transporte. Tampoco afirmamos que todas las plataformas implementen las seis capas con los mismos límites. El mapa es deliberadamente funcional: permite formular la siguiente pregunta y elegir evidencia proporcional sin inventar arquitectura.
La precisión de la capa observada es el criterio final de calidad.