A nível global

Em termos globais ambos revisores perceberam o intuito e o valor do artigo conforme foi pretendido pelos autores.

Secção 1

[x] Os autores apontam para TSN como uma solução, mas não introduzem o que é TSN. É necessária uma breve introdução a TSN.

Secção 2

[x] Esta secção começa logo com TSN: há que definir melhor o que é TSN logo no início desta secção: se é um algoritmo, um software, um mecanismo, ou uma norma…
[x] Os cenários desta secção não estão muito bem estruturados e por vezes podem ser enganadores. Por exemplo, na página 4, TSN não é a única norma que lida com questões de sincronização temporal: TTEthernet também e até é mais usado que TSN em meio automotive. A vantagem do uso de TSN é que o TSN permite mixed-criticality, permitindo ambos hard- e soft-deadlines.
- Sugestão do revisor:
  1. Definir requisitos de criticalidade em diferentes cenários;
  2. indicar tecnologias atuais para suportar cada nível de criticalidade;
  3. indicar TSN como uma solução integrada para lidar com todas as criticalidades.
Resposta minha: Não sei se é propriamente um ponto que eu queira transmitir, a questão de mixed-criticality em cenários habituais. A minha ideia era transmitir cenários habituais de TSN e, na smart city, olhar para TSN pela capacidade de mixed-criticality que a abordagem admite.
[x] Os cenários desta secção têm falta de referências. Por exemplo, existem já papers que propõem o uso de TSN com ADAS (secção 2.1), assim como também já há artigos que propõem arquiteturas para IIoT incluindo OT/IT com avaliações promissoras (secção 2.2).

Resposta minha: acho que isto está feito de alguma forma, e estaria só a complicar e dar destaque a casos concretos… Por mim diria que este ponto está completo.

Secção 3

[x] Os autores são encorajados a restruturar o paper: esta secção introduz o TSN que é necessário na secção 2.
[x] Os conceitos-base de TSN são demasiado longos. Recomenda-se que se definam subseções para cada norma para ajudar o leitor.

Secção 4

[x] Os autores são encorajados a dar mais informação acerca do algoritmo usado para fazer o escalonamento em causa: array-based algorithm, flexible window scheduling, zero-jitter algorithm, … ou caso os autores tenham desenhado um novo, fazer uma descrição do mesmo.

Resposta minha: disse que escolhemos fazer um round-robin de filas de transmissão por motivos de teste.
[x] Esta secção é muito bulky.
- Sugestão do revisor:
  1. Deixar as secções 4.1 e 4.2 tal como estão.
  2. Passar o resto para uma nova seção 5.
[x] O que é que os autores sugerem para resolver o problema de tráfego ocasional numa agenda? ou tecnicamente não-periódico? Há algum trabalho relacionado?

Resposta minha: Isto está escrito no documento, talvez de forma algo mais distribuída pelo texto… Mas entretanto adicionei (antiga página 19)
[x] E em termos da escalabilidade do TAS ou do CBS, há algo a dizer? Numa smart city onde este problema está bem mais out-scaled, acham que o TAS e CBS funcionam?

Resposta minha: Tentei responder a isto com um parágrafo algo estranho, antes da nova secção.
[x] Na secção 4.5 a análise das diferentes combinações de shaper e/ou launch time a ser ativado é interessante e dá um estudo e perspetiva únicas.
[x] Na secção 4.5 descrevam o layout da rede física (a topologia de teste) com mais detalhe, como com parâmetros como “quão longas eram as distâncias entre os nós”, … Acima de tudo, deixem todos os parâmetros considerados suficientes para se reproduzirem os resultados.

Resposta minha: No máximo acho que se pode dizer que os testes foram conduzidos em ambiente laboratorial e não de cidade? Escrevi isto na legenda da figura.
[x] Nas secções 4.5 e 4.6 comentem algo mais em termos da precisão de medição.