1

Desarrollo de SoftwareEmbebido para TVD

Aruro Zambrano arturo@lifia.info.unlp.edu.ar

2

Parte 1: Arquitectura de Ginga.ar

Parte 2: Ports para dispositivos embebidos

3

Agenda Parte 1

Context Overview of STB architecture and Ginga Issues Alternative architecture Consequences Conclusions

4

Context: Digital TV

Mux

Audio & Video

Data / Applications

Transport Stream

5

Context

Argentinian government requested porting

Ginga-NCL to a proprietary dedicated hardware platform:

The solution must ease future ports to other platforms

Code must be released under an Open Source License

Set Top Box

6

Overview: Set top box

7

Basic Firmware

8

Overview: Ginga

9

Overview: Ginga

Middleware Specification ABNT 15606

Implementation Proprietary Software GPL

The reference GPL licensed implementation of Ginga NCL developed by Telemidia Lab,

PUC-Rio

10

Ginga-NCL PUC

11

Who does what?

12

Issues (Ginga PUC)

One process does everything Integrability Licensing Stability

Processing of the Transport Stream Incomplete application signaling No support for over the air update Incomplete DSM-CC implementation

13

Ginga-NCL PUC Modules

Presentation engine

TS processing

14

Alternative Architecture

15

Alternative Architecture

16

Multi Process Architecture

Zapper Zapper Services (Proprietary) Ginga Connector (LGPL) Hardware Services (Proprietary)

Ginga Presentation Ginga-NCL Presentation Engine (GPL) Ginga Connector (LGPL)

17

Multi Process: Consequences

Benefits Licensing:

Ginga evolution Porting

Improved integrability Stability Easier testing

Drawbacks Resource Consumption Process Status Synchronization

18

Conclusions

A new multiprocess architecture for GingaNCL was developed and ported to dedicated hardware. (Working on the 2nd platform now)

The new architecture allows: Easy integration with propietary firmware Improved stability Improved GingaNCL evolvability

More information: comunidad.ginga.org.ar

Ahora vamos por la 4ta o 5ta

19

Thanks for your attention!

Questions?

20

Ginga Connector

Tuner Control CA Control MPEG-2 Section Filter TS Processing

Basic Sections (PAT,NIT,SDT,TOT) Data/Object Carousels (DSM-CC) Application Signaling (AIT) Downloading Function (SDTT)

21

Application Signaling (AIT)

Implemented Simultaneous Running Applications Priority External Applications Object Carousel Transport

Future TCP/IP Transport

22

Download Function

Implemented Support for On The Air Updates Engineering Service Compulsory Downloads Integrity Check

Future Scheduling of downloads

23

DSM-CC

Implemented Version Checking Updates Memory Usage Optimization Support for Large Carousel

Maximum File Size: 255MB Maximum Modules:

Compression of modules

Future Support for two-layer carousels

24

Parte 2

La experiencia de proyecto portando Ginga.ar

25

Port Ginga a hardware específico

Proyecto: corregir/completar la implementacion de Ginga NCL (PUC-Rio), y portarla a un set top box + intregrarlo con un Zapper.

Plataforma: Chipset ST + ST Linux:

48 MB RAM

64 Compact Flash

2 procesadores dedicados + 1 gral.

26

CondimentosHardware específico: no es un típico desarrollo en PC.

Ginga: un socio de desconocido que viene de la academia.

Zapper: otro socio desconocido, que viene de la industria.

Alcance incierto.

Tiempo hasta primer release: corto pero desconocido (política!).

Licencias incompatibles (GPL vs propietaria).

27

Hardware: Maqueta de TVD

TransmisiónRecepción 3 meses paraconseguirlo!

1.5 mesespara conseguirlo

28

Ginga-PUC

Assessment

Bug fixing

Memory leaks

Refactoring

29

Zapper

Inestabilidad

Bugs y memory leaks

Código de terceros que no podíamos modificar (podíamos pedir cambios).

30

Problemas

Escasez de hardware para pruebas.

Grandes volúmenes de prueba (estamos probando un middleware!).

Estabilidad.

Licenciamiento.

31

Arquitectura Ginga.ar

Estabilidad + Licencias + Mejor Modularización + Portabilidad

32

Proceso

Mezcla de Scrum y Kanban

Scrum:

Iteraciones de 1 a 2 semanas.

Planificación por Sprint

Kanban

Aceptamos stories todo el tiempo (relegamos otras que habian entrado en el sprint).

Tratamos (informalmente) de mantener el límite de Work in Progress.

33

Desafíos de testing

Testear el middleware que permite usar aplicaciones interactivas.

Esta embebido, no en una PC.

Consume grandes volúmenes de información (Transport Streams).

Muchísimos (infinitos) casos de prueba.

34

Testing

Aplicaciones NCL autogeneradas.

Aplicaciones “de testing” manual.

Simulación de hardware.

Compilación multiplataforma (x86 y embebido).

35

Testing - Manual

De output visual

Tests de stress: actualizaciones y aplicaciones

36

Testing automático

Testing nocturno.

Mediciones: memoria, consumo de CPU, core dumps, logs, etc.

Transport stream generados automáticamente con actualizaciones del firmware.

37

Plataforma de testing automático

38

Testing automático

Scripts de interacción (contro remoto)

Cambio de canal → Zapper

Ejecución de aplicaciones• Desde el aire

• Desde pendrive

Parsing de TS

39

Ingeniería de Software y herramientas

Pair programming para código crítico.

Automatización de builds (Cmake)

Integración continua (Build Bot)

Testing de unidad e integración (parsing de TS) automatizado (GoogleTest)

Casi Scrum (Redmine + SA Plugins)

40

Resumen

Embedding de Ginga en la plataforma de destino.Embedding de Ginga en la plataforma de destino.

Problemas de estabilidad y de escases de recursos.Problemas de estabilidad y de escases de recursos.

Prácticas provenientes de las metodologías ágiles.Prácticas provenientes de las metodologías ágiles.

Automatizamos todo lo que pudimos (y como Automatizamos todo lo que pudimos (y como pudimos)pudimos)

41

Conclusiones

Para desarrollar software embedido hay que considerar:

Plataforma de hardware y software subyacente

Familiaridad el proceso de embedding Si van a usar linux:

Compatibilidad de licencias del software que usen.

Considerar el testing desde el ppio. Porque es software que no deberia fallar (un aparato de TV NO deberia colgarse)