Desarrollo de Software Embebido para TVD - » es:main
Transcript of Desarrollo de Software Embebido para TVD - » es:main
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)