Il livello di ridondanza – Part 4

Ben ritrovati! Chi si fosse perso le puntate precedenti è invitato a recuperale qui:

Lo studio di un progetto reale aiuterà a capire il procedimento che si deve utilizzare per valutare quali siano “i colli di bottiglia” e per incrementare il livello di ridondanza al fine di raggiungere gli standard adeguati alle varie applicazioni.

Figura 6.4: Schema generale del network nello studio 11

Esempio del nuovo Studio 11

Qualche hanno fa ho avuto l’occasione di dare il mio contributo alla progettazione, installazione e test del ristrutturato Studio 11, divenuto così il primo studio Full HD del principale broadcaster privato italiano. In occasione della ristrutturazione della parte tecnica, sono stati installati apparati e network totalmente nuovi, sia per audio che per video.
Si prenderà in esame una porzione del progetto audio, della quale si analizzeranno il network e i task di principale interesse.

Breve descrizione del sistema

Lo studio è composto della parte di teatro e dalle varie zone tecniche quali la regia audio, la regia video, la sala grafica, la sala macchine e l’area service (nella quale vengono ospitati operatori e mezzi di aziende esterne incaricate di alcune produzioni).
Il network audio principale, schematizzato in figura 6.4, è Optocore.
Diversi apparati X6-FX sono dislocati nei diversi punti del teatro per effettuare la raccolta di segnali microfonici e la distribuzione dei vari ascolti, alcuni DD32E sono utilizzati per gli I/O AES3 della grafica e la postproduzione video, altri DD32E (AES3), DD4ME (Madi Coassiale), DD2FE (Madi Ottico) e YG2 (inserita in un Yamaha DME64) sono posti in regia audio, della quale si andranno a vedere le connessioni più in dettaglio.

I network device di Optocore offrono tutti livelli A3, ad eccezione della scheda YG2 per la quale il livello specifico di ridondanza della classe power dipende dalle caratteristiche dell’apparato che la ospita, in quanto riceve alimentazione dallo slot di espansione dei prodotti Yamaha. L’engine DME64 che alimenta la YG2 non è dotato di PSU ridondante e tale limitazione si ripercuote, in virtù della predominanza del livello inferiore, sul livello dell’intero network che risulta essere A2, che, per analogia con il già descritto A3, si intende con A2 (wiring, synch) nel quale manca la classe power.

Questa è la prima occasione nella quale si può pensare a come ovviare a questa limitazione e incrementare il livello.
Non essendo disponibile una versione del DME64 con doppio PSU occorre valutare alternative di collegamento tra il network e lo stesso DME64, per far sì che l’eventuale avaria della foglia non si “trasmetta” al network. Questo si ottiene sostituendo la YG2 con un DD32E e introducendo nel DME64 una scheda di espansione Yamaha che prevede scambio audio in formato AES3, tipo la MY16AE . In questo modo si ottengono gli stessi risultati dal punto di vista audio (8x AES I/O tra Optocore e DME64) ma si dividono i rischi relativi alla classe power tra la foglia e il network. Come spesso avviene, questo aumento del livello di ridondanza non è a costo zero, in quanto l’insieme DD32E + MY16AE è più costoso della precedente soluzione rappresentata dalla sola YG2.

I task, i path e le zone principali

Senza voler scendere troppo in dettaglio, si vuole ora capire quale sia il task principale al fine di valutare se il progetto adottato offre garanzie adeguate al livello di aspettativa del committente.
Essendo lo studio concepito per produzioni sia di programmi registrati e postprodotti che trasmissioni live, occorre prevedere soluzioni ridondanti che permettano la non interruzione del servizio e che eventuali procedure di emergenza possano essere invocate nell’arco di pochi secondi.
Vent’anni fa non di rado appariva in TV la scritta “Le trasmissioni riprenderanno il più presto possibile” con tanto di sottofondo musicale che poteva rimanere per svariati minuti; oggi il telespettatore selezionerebbe immediatamente un programma diverso con ripercussioni sui risultati auditel e le annesse conseguenze commerciali. Costa meno prevedere livelli di ridondanza superiori che pagare penali agli inserzionisti pubblicitari.

Si può individuare nel task MESSA IN ONDA quell’insieme di apparati che garantiscono che l’audio essenziale del programma possa essere inviato all’embedder audio/video e successivamente alla stazione di emissione. Non interessa ora entrare nel dettaglio della definizione di cosa si intenda per audio essenziale , ma ci si limiterà a valutare la parte più delicata del sistema e cioè la connessione tra il network e la console, in quanto è da questo path che fluisce la quasi totalità dei segnali in gioco.
La console di missaggio principale è una SSL C100 che riceve uno stream madi ottico da 64 canali dalla porta A di un DD2FE, mentre la console di backup, una SSL C10, riceve lo stesso stream madi ottico dalla porta B del medesimo DD2FE. Le console main e spare restituiscono i segnali mixati al DD2FE per mezzo di due stream madi ottici da 64 canali cadauno.
Il sincronismo dell’intero studio è fornito da un PG che genera il BB PAL che, per mezzo di vari distributori, viene consegnato a tutti gli apparati video e audio che lo possono ricevere direttamente (le consoles SSL accettano direttamente il BB), mentre, per mezzo di un convertitore, viene generato un word clock a 48kHz derivato dallo stesso BB per fornirlo agli apparati che accettano solo quest’ultimo segnale di synch (il network Optocore all’epoca accettava solo Word Clock, così come i ricevitori dei radiomicrofoni utilizzati).

Figura 6.5: Prima versione della zona Optocore-SSL

Si analizzi il livello di ridondanza della zona Optocore-SSL, cuore del task MESSA IN ONDA, in questa sua prima versione, schematizzato in figura 6.5: Sapendo che sia Optocore che SSL sono A3, considerando le connessioni madi locali e protette ed avendo previsto la sopravvivenza anche in caso di fault della console main C100, possiamo affermare che la zona OPTOCORE-SSL ha livello 4, più precisamente

La classe C100 è semi-automatica perché in caso di fault occorrerà azionare un pulsante che cambierà il patch del segnale inviato all’embedder prelevandolo dalla console spare C10 anziché dalla main C100. Lo stesso vale per i segnali degli ascolti che ritornano verso il network per essere distribuiti al resto dello studio e in teatro.

Si potrebbe affermare che un livello 4 sia già un buon risultato, ma osservando di nuovo lo schema appare chiaro che si sono spesi tanti soldi per avere un’intera console spare ma il suo reale impiego dipende comunque dal corretto funzionamento dello stesso device Optocore DD2FE che scambia segnali con la main. Questo significa che l’eventuale fault del DD2FE rende di fatto inutile la presenza della console spare.

Dal livello 4 al livello 5

L’analisi della zona può essere facilitata valutando i path che la compongono: DD2FE-C100 e DD2FE-C10 non sono disgiunti (hanno il DD2FE in comune). Per l’incremento di ridondanza della zona occorre rendere i due path distinti ed indipendenti.
In regia audio è già previsto un altro apparato Optocore con porte madi per il collegamento di una matrice audio/video e dell’area service; si può pensare di ridistribuire i compiti delle 4 porte I/O madi dei due device Optocore al fine di garantire path distinti nella zona Optocore-SSL, come riportato nello schema di figura 6.6

Figura 6.6: Path distinti per main e spare

Per fare questo si è reso necessario l’utilizzo di un media converter che permette al madi coassiale proveniente dal DD4ME di diventare madi ottico prima di giungere alla C10 e viceversa per i segnali dalla C10 al DD4ME. Si faccia molta attenzione nella scelta del media converter in quanto entra a far parte del path e della zona e non deve quindi rappresentare un collo di bottiglia per il livello di ridondanza. In altre parole deve essere dotato di doppio PSU ed avere caratteristiche costruttive e di affidabilità dello stesso livello delle altre apparecchiature utilizzate.

Il livello di ridondanza della zona è quindi salito di un’unità in quanto ora si garantisce il servizio anche in caso di fault del DD2FE. Si ha quindi

La classe DD2FE è anch’essa semi-automatica non perché si debba azionare il backup DD4ME (che è sempre funzionante) ma perché si dovrà utilizzare la console spare, ricadendo nel caso precedente per ciò che riguarda i cambi di patch necessari.

Ci si potrebbe accontentare di un livello 5, poiché per avere interruzione significativa si deve effettivamente verificare un importante numero di inconvenienti contemporanei, ma se si volesse proseguire nell’innalzamento del livello, come si potrebbe fare?

Per capire cosa potrebbe servire occorre provocare virtualmente l’interruzione di servizio e scoprire da cosa è stata causata. Oltre al banale caso di contemporanea rottura di entrambe gli apparati Optocore o di entrambe le console SSL (prima o poi ci si deve fermare e solitamente la regola “due di tutto” dovrebbe bastare) si possono verificare casi particolarmente sfortunati nei quali vengono a mancare elementi diversi in path distinti.

Il fault del DD2FE (main Optocore) accompagnato dal fault della C10 (spare SSL), o il duale DD4ME+C100, portano di fatto all’interruzione del servizio nonostante la situazione paradossale di avere ancora un device del network ed una console perfettamente funzionanti, ma semplicemente non in comunicazione tra loro, come riportato in figura 6.7 .

Figura 6.7: Esempi di fault contemporanei fatali per la zona

Dal livello 5 al livello 6

Se il budget per l’aumento del livello è terminato, si può solo prevedere un cambio di connessioni manuali (scambio di fibre). Questa procedura di emergenza può essere effettuata nell’arco di qualche minuto, cosa che può risultare funzionale nel caso di trasmissioni registrate e postprodotte, ma non nel caso di eventi in diretta.

Se si accettasse il cambio di fibre manuali si potrebbe indicare il livello del sistema nel modo seguente:

Si noti che per il livello 6 manuale si è indicata la contemporaneità dei guasti elevando a classi DD2FE + C10 e DD4ME + C100. Si noti inoltre che sarebbe sbagliato assegnare livello 7 tenendo i due eventi distinti in quanto, ai fini dell’analisi, che si rompa la prima o la seconda coppia è del tutto equivalente: uno dei due path deve comunque sopravvivere per garantire la continuità del servizio.
Questo è il tipico caso che si presenta quando si pongono apparati spare e main all’interno dello stesso path.

Risorse aggiuntive per l’incremento di livello

Se all’intervento manuale si preferisse un intervento semi-automatico (più che sufficiente per garantire un livello 6 in queste situazioni) si potrebbe far ricorso ad apparati aggiuntivi. Si faccia molta attenzione a non peggiorare la situazione, ricordandosi che device aggiuntivi servono per aumentare il livello globale di sicurezza, tenendo sempre a mente che “quello che c’è si può rompere, quello che non c’è non si rompe” e non finire per ribaltare la situazione arrivando paradossalmente ad avere malfunzionamenti proprio a causa di risorse non fondamentali che si erano introdotte per evitarli.
Esistono sul mercato dei device robusti, semplici dal punto di vista del layout costruttivo e con componenti di comprovata affidabilità che effettuano semplici operazioni. Tali apparati sono perfetti per aumentare il livello di ridondanza e non hanno nemmeno costi elevati. Nella loro scelta si consiglia di non farsi attrarre da modelli più sofisticati o con molteplici funzioni anche se il costo di quest’ultimi non fosse molto superiore alle versioni base. Meno funzioni hanno, meno componenti montano, più semplici da utilizzare sono, meglio è.

Nell’esempio in analisi si potrebbero utilizzare degli ottimi prodotti della tedesca Direct Out Technologies (DO.TEC) ed in particolare i modelli denominati MADI SPLIT.CONVERTER. Dotati di PSU ridondanti con cavi di alimentazione separati, offrono 4 porte I/O madi, due di tipo ottico e due di tipo coassiale, per mezzo di semplici ed affidabili selettori manuali permettono la scelta dello stream sorgente per ogni output, tra tutti i quattro disponibili. Combinando opportunamente le posizioni dei selettori si può quindi effettuare sia madi splitting che format conversion.

Si aggiungano quindi due Split.Converter e si colleghino come da schema in figura 6.8.

Figura 6.8: Due Split.Converter per livello 6 semi-automatico

Così facendo sia console main che spare possono prelevare segnali da entrambe i device madi Optocore, semplicemente modificando la posizione di un selettore. La stessa cosa è possibile fare per i segnali che dalle console main e spare sono inviati verso i device Optocore.
Per evitare di fare confusione nei termini, si sottolinea che per la console main (C100) è considerato main il device Optocore DD2FE (collegamento di default), mentre funge da spare il DD4ME (collegamento che avviene solo in caso di emergenza). Considerando la console spare (C10) i ruoli dei device Optocore si invertono: il DD4ME rappresenta il main mentre lo spare è il DD2FE.
Il discorso duale si deve fare per gli ingressi dei device Optocore: per il DD2FE è main il segnale che proviene dalla C100, mentre per il DD4ME è main quello proveniente dalla C10.
In nero si sono indicate le posizioni di default dei vari selettori e cioè quelle che si hanno in condizioni normali, in rosso quelle da adottare in caso di emergenza.

La zona così composta ha quindi livello 6 semi-automatico ovvero:

La soluzione proposta ha anche un effetto collaterale positivo e cioè permette al fonico di continuare ad operare sulla console principale in caso di fault del solo DD2FE, cosa che non poteva avvenire secondo lo schema adottato in figura 6.6 che obbligava comunque al passaggio sulla console spare.

Dal livello 6 al livello 7

Cos’altro si può prevedere? Quali altre insidie vi possono essere tra il network Optocore e le consoles SSL? Se accadesse qualcosa al sistema di distribuzione del BB o all’estrattore di clock, ci si potrebbe trovare nella spiacevole condizione nella quale network e console non siano più sincroni, con immancabili glitch continui che renderebbero l’audio inascoltabile. Se si dovessero prevedere soluzioni ridondanti per i distributori presenti nello studio si dovrebbe investire una considerevole somma di denaro e si complicherebbe in maniera pesante il layout dei cablaggi dell’intero studio, senza la certezza di avere sempre una soluzione per i collegamenti tra network e console.
In questi casi, se si vuole avere un livello superiore che contempli un generico fault del synch generale è molto meglio prevedere degli apparati che effettuino sample rate conversion tra le parti del sistema che si ritrovassero ad essere non più sincrone tra loro.
Questa possibilità la si paga sia in termini monetari che in termini di latenza in quanto tale conversione richiede un minimo di tempo di calcolo.
Si prevede allora l’utilizzo di apparati DO.TEC Madi.SRC che effettuano sample rate convertion di uno stream madi da 64 canali in maniera unidirezionale impiegando 2 millisecondi. Tale latenza aggiuntiva è assolutamente accettabile, anche per eventi live, in questo punto del sistema.

Figura 6.9: Schema funzionale di un SRC

La funzione dell’SRC, schematizzata in figura 6.9, è quella di risincronizzare i segnali provenienti dall’apparato asincrono in base al clock dell’apparato destinatario dei segnali. Per fare questo occorre che l’SRC riceva il riferimento di clock, per mezzo di un cavo coassiale, dall’apparato al quale invierà il segnale madi. Così facendo, l’SRC è asincrono rispetto al mittente ma sincrono con il destinatario, con il risultato che il device destinatario può correttamente ricevere il segnale dal mittente nonostante funzionino in maniera tra loro asincrona.

Nella ipotesi più catastrofica di totale perdita del BB generale, sia Optocore che le console SSL passerebbero automaticamente al clock interno (sono entrambe A3 con classe synch inclusa) trovandosi tra loro asincroni, ma grazie all’inserimento manuale dell’SRC si “protegge” la zona e si garantisce la non interruzione del servizio.

Per risparmiare un po’ di denaro, si decide di non prevedere SRC separati per ogni console, ma uno solo al quale si inviano i segnali della console main o spare al bisogno, secondo lo schema riportato in figura 6.10.

Figura 6.10: Segnali dalle console con possibilità di SRC

Segue una breve descrizione di questo layout.

Porta A La porta A dello Split.Converter riceve in ingresso il segnale madi dalla console main C100 e alimenta l’ingresso madi del DD2FE. Il selettore A di norma posizionato su A e cioè, in condizioni normali, al DD2FE arriva il segnale diretto e sincrono della console main C100. Il selettore A viene spostato sulla posizione B in caso di fault della console main C100 al fine di alimentare il DD2FE con i segnali provenienti dalla console spare C10. La posizione C del selettore A è utilizzata nel caso di perdita di sincronismo generale per inviare al DD2FE il segnale proveniente da una delle console che abbia subito il processo di SRC. Se la console sorgente debba essere la main o la spare lo si decide per mezzo del selettore C.

Porta B Di questa porta si utilizza il solo connettore di input, per far giungere allo Split.Converter il segnale madi ottico proveniente dalla console spare C10. Visto che la porta di uscita non è sfruttata, la posizione del selettore B è del tutto ininfluente.

Porta C L’Out della porta C invia all’SRC il segnale di una delle due console. Il selettore sarà posto normalmente su A e cioè si decide che la prima scelta debba essere la C100. Se invece occorrerà inviare il segnale proveniente dalla C10 si dovrà spostare il selettore in posizione B. L’In della porta C riporta all’interno dello Split.Converter il segnale processato dall’SRC.

Porta D L’In di questa porta non è utilizzato, mentre l’Out invia il segnale della console spare C10 (selettore normalmente su B) o della console main C100 (selettore in posizione di backup A) verso il DD4ME.

Per completare il lavoro, in maniera duale si prevede un’altra accoppiata Split.Converter/Madi.SRC con collegamenti analoghi per i segnali che dagli apparati Optocore raggiungono le consoles.

La zona così composta salirà allora di un’altra unità, prevedendo una soluzione di emergenza anche nel caso di perdita totale del sincronismo generale del sistema arrivando ad avere livello 7:

Quest’ultima soluzione garantisce effettivamente livello 7, ma presenta un grandissimo difetto: i segnali da console main e spare attraversano lo stesso Split.Converter; lo stesso succede per i segnali che dai device Optocore giungono alle console.

Si è fatto tanto per avere livello 7, ma se si verifica un fault in uno Split.Converter si perdono contemporaneamente i segnali main e spare, rendendo inutili tutti gli sforzi!

Questo è il classico esempio di una soluzione apparentemente più sicura della precedente (livello 7 anziché 6), ma ottenuta non rispettando la regola che prevede path critici distinti ed indipendenti. Se si effettuasse l’analisi dei vari path main e spare tra Optocore e console di quest’ultima configurazione, si noterebbe infatti che c’è sempre uno Split.Converter in comune, che rende i path non distinti e non indipendenti.

Si propongono dunque soluzioni nettamente migliori.

Livello 7 con layout migliori

Si può correggere l’errore commesso utilizzando gli stessi apparati, ma adottando un diverso schema di collegamento, riportato in figura 6.11.

Figura 6.11: Split.Converter distinti per segnali main e spare

Quest’ultima soluzione garantisce che i segnali main e spare di console e Optocore attraversino Split.Converter distinti.

Lo schema di figura 6.11 è migliorativo, tuttavia presenta effetti collaterali non desiderabili:

  • si è parecchio complicato l’utilizzo dei selettori degli apparati Split.Converter e Madi.SRC rendendo più lunghe e complesse le procedure di sicurezza
  • i segnali di scorta devono attraversare il device Madi.SRC anche quando non ci sarebbe bisogno della sua funzione, sottoponendoli inutilmente a rischio di fault di tale apparato.

Si propone infine la soluzione che si ritiene la più completa, sicura e di facile utilizzo, ottenuta con quattro Split.Converter e due Madi.SRC secondo lo schema di figura 6.12.

Figura 6.12: Soluzione più completa, sicura e di facile utilizzo

Al fine di comprenderne il funzionamento si riportano i dettagli dei selettori per i vari Split.Converter nelle figure 6.13, 6.14, 6.15, 6.16.

Quest’ultima soluzione racchiude diversi vantaggi:

  • garantisce path critici indipendenti
  • minimizza gli interventi da effettuare sui selettori dei vari Split.Converter in caso di emergenza
  • separa i compiti dei vari Split.Converter per funzione
  • fa attraversare i segnali di console e nodi Optocore nei Madi.SRC solo se necessario
  • non prevede nessun cambio necessario delle opzioni a bordo degli apparati che effettuano l’SRC, che vengono pertanto preimpostati al momento dell’installazione e non più modificati, nemmeno in caso di emergenza.

Si noti che il costo dei sei apparati DO.TEC per passare da livello 5 a livello 7 è solo una frazione del costo della console spare o equivalente a un paio di nodi del network Optocore.

Figura 6.13: Split1: instrada segnali a console main e Optocore main

 

Figura 6.14: Split2: instrada segnali a console spare e Optocore spare

 

Figura 6.15: Split3: attiva SRC per segnali dalla console main o spare

 

Figura 6.16: Split4: attiva SRC per segnali dall’optocore main o spare

Il livello residuo dopo un fault

Può essere utile valutare quale sia il livello di ridondanza residuo dopo che si è verificato un fault. Se si considera il sistema generale spesso il livello residuo è 0 in quanto un ulteriore fault porterebbe all’interruzione, ma non è detto che lo sia per path, zone o task principali.
In ogni caso questo approccio aiuta ad ottimizzare la progettazione e fa emergere eventuali aspetti migliorabili quali connessioni alternative tra nodi del network e loro corretta sequenza, al fine di minimizzare l’impatto negativo dell’ulteriore fault che si dovesse verificare.

Si prenda di nuovo l’esempio dello Studio11 e si consideri il collo di bottiglia rappresentato dalla mancanza di doppio PSU per la YG2 inserita nel DME64.
Nella regia audio sono fisicamente collocati i seguenti devices, come da schema in figura 6.17: DD4ME, DD2FE, YG2, DD32E. Quest’ultimo introduce nel network i segnali AES3 provenienti dai ricevitori di tutti i radiomicrofoni utilizzati nel teatro, cioè i segnali live più importanti quali il radiomicrofono del conduttore e degli ospiti principali che, attraverso i nodi DD2FE e DD4ME, raggiungono le console main e spare.

Figura 6.17: Sequenza dei nodi in regia audio

Grazie alla struttura ad anello, una volta entrati nel network i segnali saranno disponibili ad ogni nodo, indipendentemente dalla sequenza di collegamento dei nodi stessi.
Quando tutto funziona correttamente e tutte le fibre sono connesse, il doppio anello garantisce la ridondanza, nel senso che si ha un doppio percorso tra tutti i nodi, quello che gira in senso orario e quello in senso contrario.
L’eventuale power fault del DME64 che contiene la YG2 ha impatto sul network, in quanto fa perdere completamente il nodo YG2 e, di fatto anche le fibre che ad essa erano collegate.
Il network minimizza automaticamente l’impatto di questo fault, ricostituendo un anello funzionante tra i nodi residui, come si osserva nello schema di figura 6.18.

Figura 6.18: Anello ricostituito tra i nodi superstiti

In questa nuova situazione, il fatto che i segnali dei radiomicrofoni possano raggiungere le console (via DD2FE o DD4ME) dipende dalla futura integrità di tutti i nodi e le fibre che separano il DD32E e i nodi madi (DD2FE e DD4ME).

In altre parole sarà sufficiente un’ulteriore avaria di uno qualsiasi dei nodi intermedi per perdere la porzione più importante dei segnali.

Senza spendere un euro in più, ma semplicemente ottimizzando la sequenza di connessione all’interno della regia audio, si può ovviare a tutto questo.
Si invertono allora le posizione di DD32E e YG2 in modo che i segnali dei radiomicrofoni possano arrivare ai nodi madi indipendentemente dalla funzionalità degli altri nodi del network, come si evince dallo schema in figura 6.19, nel quale si è ipotizzato un ulteriore fault con lo spezzamento in due del network.

Figura 6.19: Sequenza più efficace in caso di network spezzato

Osservando lo schema di figura 6.19 e seguendo il filo logico di quanto fatto in precedenza per aumentare il livello della zona Optocore-SSL, si nota che l’eventuale perdita del DD2FE coinvolgerebbe anche i segnali provenienti dai radiomicrofoni.
La sequenza migliore allora non è quella appena proposta, ma quella di figura 6.20 nella quale si è posto il DD32E tra i device madi. In questo modo sarà sufficiente che funzioni almeno un nodo madi affinché i segnali dei radiomicrofoni arrivino alle console.

Figura 6.20: DD32E posto in mezzo ai nodi madi, per la massima sicurezza

La prossima puntata vedremo quale sia la sequenza dei passi da seguire per una corretta progettazione, per oggi ci fermiamo qui.

A presto!

Luca Giaroli
ZioGiorgio Contributor

info: www.lucagiaroli.com

Vai alla barra degli strumenti