Trabalhos de Fim de Curso: - Departamento de Engenharia ...

INSTITUTO
SUPERIOR
TÉCNICO
SECÇÃO DE
SISTEMAS
Trabalhos de Fim de Curso:
Documentação e
Normas de redacção e apresentação

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 1
NORMAS DE REDACÇÃO E APRESENTAÇÃO
As disciplinas de Projecto de Sistemas I e Projecto de Sistemas II estão
integradas, tendo como objectivo fazer a síntese das matérias leccionadas
nas diversas disciplinas do curso, através da aplicação desses
conhecimentos à resolução de um projecto de engenharia.
No final, por forma a documentar e permitir a divulgação dos trabalhos
realizados, serão elaborados pelo grupo de projecto: um relatório final;
uma folha sumário do trabalho desenvolvido; um relatório interno; e um
poster, recomendando-se que os últimos três elementos sejam redigidos em
língua inglesa.
Como documentação de referência, serão entregues: três exemplares do
relatório final (integrando um CD contendo todos os elementos de avaliação em versão
editável); um do relatório interno; um da folha de sumário e um poster.
A avaliação do projecto é efectuada através de oral pública, individual por
trabalho, realizada por um júri, nomeado pelo responsável das disciplinas.
A classificação final é atribuída com base num conjunto de factores
nomeadamente: o relatório final, a apresentação oral e a discussão do
projecto.
Dez por cento da nota final corresponde à avaliação periódica da evolução
do projecto, a qual consta da entrega de uma folha sumário e uma
apresentação sumária (~10 min) dos trabalhos em curso por cada um dos
grupos – baseada em acetatos explicativos dos trabalhos desenvolvidos, em
curso e futuros – e da entrega de um relatório intercalar, com o máximo de
dez páginas.
Dos parágrafos anteriores (extraídos das regras para elaboração do Projecto
de Sistemas I e II, enquadradas nas Regras Gerais de Projectos definidas
DEM), conclui-se da necessidade de se elaborarem diversos tipos de
documentos escritos e de serem apresentadas diversas comunicações orais
com apoio audiovisual, para cumprir as exigências estabelecidas e concluir
com sucesso a disciplina.
É sentimento comum, entre os professores orientadores dos trabalhos de fim
de curso, que os jovens formandos, apresentam enorme dificuldade em se
exprimirem correctamente.
Desconhecendo as regras mínimas de apresentação das diferentes peças
escritas que se lhes solicita, os alunos apresentam documentos avulso, em
que investiram grande parte do tempo dedicado à disciplina, mas onde,
muitas das vezes, não conseguem mostrar o trabalho, que, brilhantemente,
foram desenvolvendo ao longo de dois semestres. É sempre nas últimas
horas que os tutores têm oportunidade de criticar as provas, apontando os
caminhos e traçando orientações, já tardias, para uma redacção mais
eficiente. Raramente, porém, tais conselhos extravasam os limites da
documentação escrita. As apresentações orais e os seus apoios audiovisuais
não são objecto de discussão com o discente para além da indicação de
leves referências.
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 2
Temos, os docentes, de assumir a responsabilidade que nos cabe nesta
lacuna da formação dos nossos alunos. Podemos afirmar, com razão, que
não é da nossa responsabilidade as deficiências de expressão oral e escrita
dos nossos orientados, que tal se deve a razões pedagógicas, cujos
problemas têm raízes no ensino secundário. Porém não podemos negar que
nos compete a nós a preparação dos nossos discípulos para que estes
possam vir a ocupar o seu lugar na comunidade cientifica. A ser assim, e
porque se trata de uma comunidade que obriga os seus membros a produzir
(relatórios, propostas de projectos, intervenções e comunicações) para
sobreviver, somos os primeiros responsáveis porque eles saibam comunicar
os seus trabalhos científicos.
Tem este texto a intenção de colmatar aquela lacuna, apresentando linhas
orientadoras, ainda que generalistas e necessariamente incompletas, da
escrita e comunicação em ciência. Pretende-se que os nossos estudantes
possuam um manual que os guie na estruturação dos seus escritos e na
elaboração das suas apresentações.
A panóplia de documentos escritos a apresentar para avaliação, podem
resumir-se aos tipos, Monografias, Artigos e Notícias, aos quais se
acrescentam os Acetatos e Cartazes, para apoio das Apresentações Orais.
Serão estes, porque necessários à disciplina, que iremos abordar e
descrever ao longo destas páginas.
1. RELATÓRIO DO TRABALHO DE FIM DE CURSO
O Relatório do Trabalho de Fim de Curso (TFC) é uma monografia , pois é
um tipo específico de trabalho cientifico, que se reduz à abordagem de um
tema específico do conhecimento. As teses de doutoramento e as
dissertações de mestrado são também monografias.
As monografias caracterizam-se pela delimitação e aprofundamento do tema
escolhido, recorrendo, para se fundamentar, à pesquisa bibliográfica.
São orientados para a realização de um trabalho concreto …tendo como
objectivo fazer a síntese das matérias leccionadas nas diversas disciplinas do
curso, através da aplicação desses conhecimentos à resolução de um projecto de
engenharia (In Regras para elaboração do Projecto de Sistemas I e II).
A estrutura dos TFC’s deve seguir o sistema adoptado para as
monografias, e não ter mais de 80 páginas:
1.1. CAPA
Inclui o nome do autor, título do trabalho e o ano de redacção.
Deve seguir as normas estabelecidas pelo Manual de Harmonização de
Imagem do IST.
A figura junta mostra o aspecto geral (e informações úteis) sobre a página
que deve capear o relatório.
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 3
As capas de relatório são
impressas a azul escuro, Pantone
287, conforme a ilustração.
Para tornar possível a
encadernação, a banda azul clara
tem mais 15 mm de largura no
lado esquerdo do que no lado
direito. As margens superior e
direita à volta do escudo são
iguais ao restante material
impresso de formato A4.
O título, o nome do autor e o ano
de publicação, são grafados em
24/26pt em letra tipo “Times Bold”,
letra maiúscula e minúscula,
alinhado à esquerda.
As informações adicionais são
centradas impressas por sob o
título, em letra de 12pt do tipo
“Arial”.
1.2. PÁGINA DE ROSTO
Figura 1 – Capa do relatório do Trabalho de Fim de Curso
Folha imediatamente a seguir à capa
(figura 3). Inclui o nome do autor, o
número de aluno, o título do trabalho, o
ano, a localidade e o nome do orientador,
para além da identificação completa do
estabelecimento de ensino.
No verso desta folha (figura 2) deve
constar a seguinte frase:
Este trabalho reflecte as ideias dos seus autores
que, eventualmente, poderão não coincidir
com as do Instituto Superior Técnico.
1.3. AGRADECIMENTOS
200
265
INSTITUTO
SUPERIOR
TÉCNICO
SECÇÃO DE
SISTEMAS
Título …
Relatório do Trabalho de Fim de Curso
Licenciatura em Engenharia Mecânica
Ramo de Automação e Robótica
Autor …….
2004
Sendo o relatório um documento público, que poderá ser consultado na
biblioteca da Secção de Sistemas, os agradecimentos devem ser redigidos
com parcimónia. Tal não impede porém que se agradeça a todos aqueles
que contribuíram, de alguma forma, para a realização do trabalho.
Desde logo aos orientadores, a quem caberá uma palavra de apreço, e às
instituições que possam ter financiado o trabalho desenvolvido.
Rui Loureiro - 2004 Projecto de Fim de Curso
50
80
25
Ffdfdfhdhhdhhnvjvn ,
hgfgd dfgk bdsfhjd
kjdfhhdf jdhf
Ffdfdfhdhhdhhn
70
185
Figura 2 – Verso da página de rosto

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 4
Grafados a maiúsculas a 26pt, centrados
em letra tipo “Times New Roman” são o
nome da Universidade e do Instituto
(este a “Bold”). A 22pt, no mesmo tipo de
letra é grafada a restante informação,
sendo Secção de Sistemas impresso a
itálico.
O título (não mais de dez palavras) é
escrito, a 24/26pt em letra tipo “Times
New Roman Bold”, letra maiúscula e
minúscula, centrado. A informação
complementar terá grafia a “Arial Bold”
de 14pt, sendo colocada a seguir ao
título.
O nome do(s) autor(es) e o
correspondente número de aluno são
afixados em letra tipo “Times New
Roman”, maiúsculas e minúsculas,
centrado com 24pt.
O nome(s) do(s) orientador(es) é
antecedido pela expressão Trabalho
Orientado por:. Toda a informação será
grafada a 20pt, centrada e em letra tipo
“Times New Roman”.
O local e o ano de realização serão
impressos a a 16pt, centrados e em letra
tipo “Times New Roman”.
1.4. ÍNDICE
Figura 3 – Página de rosto do Trabalho de Fim de Curso
Para permitir ao leitor – em especial aos avaliadores – a rápida consulta
pelas diferentes secções e subsecções do relatório, deve ser incluída uma
paginação geral do trabalho.
A estrutura tradicional de um Trabalho de Fim de Curso é idêntica à de uma
tese ou dissertação, contendo como secções principais:
1.5. RESUMO
UNIVERSIDADE TÉCNICA DE LISBOA
INSTITUTO SUPERIOR TÉCNICO
Departamento de Engenharia Mecânica
Secção de Sistemas
Título
Relatório do trabalho de fim de curso
Licenciatura em Engenharia Mecânica
Ramo de Automação e Robótica
Nome do(s) autor(es) e número de aluno
Trabalho orientado por:
Lisboa
Ano lectivo
Introdução
Revisão Bibliográfica
Materiais e Métodos
Resultados
Discussão (pode ser incluída na secção de resultados)
Conclusões
Bibliografia
Refere o assunto a tratar e todas as informações relevantes do trabalho. É
uma visão geral e sintética dos objectivos, resultados e conclusões. Tudo o
que é novidade ou que interessa comunicar aos leitores (neste caso, aos
avaliadores) deve ser mencionado.
Rui Loureiro - 2004 Projecto de Fim de Curso
25
120
185
30
25

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 5
A versão inglesa deste resumo (Abstract) deve ser incluída, no verso, ou em
página separada.
O abstract funcionará como “folha sumário do trabalho desenvolvido”, a
entregar em separado para avaliação.
O resumo segue as regras apontadas para escrever NOTÍCIAS.
1.6. INTRODUÇÃO
Âmbito, objectivos e motivos que levaram à realização do trabalho.
A forma como o relatório foi estruturado e o que se espera transmitir em
cada secção, pode ser abordada de forma sintética.
Novas abordagens ao tema, ou limitações a que o trabalho tenha sido
sujeito, devem ser sublinhadas.
Se, em 2/3 página (uma no máximo) não se motivar o leitor a ler com
interesse o relatório, então o trabalho de redacção foi infrutífero.
1.7. REVISÃO BIBLIOGRÁFICA
Nesta secção apresentam-se as investigações relevantes realizadas por
outros investigadores, ou pelo próprio, sobre o tema. Mostre como o trabalho
se relaciona com as investigações anteriores, como o complementa ou
contradiz.
Esta secção fundamente na literatura publicada sobre o assunto.
1.8. MÉTODOS E TÉCNICAS
O que se fez, como se fez, que materiais se utilizaram e que técnicas foram
seguidas, são as bases para redigir desta secção.
Os procedimentos, descritos pela sequência correcta da sua realização, os
testes e as experiências, são partes integrantes deste capítulo, garantindo a
precisão do que foi realizado.
As metodologias e as análises estatísticas efectuadas devem ser incluídas. A
utilização de quadros, gráficos e figuras permitirão clarificar e apreender
rapidamente as características dos métodos utilizados.
Refere também as técnicas computacionais utilizadas no trabalho. As
listagens dos programas desenvolvidos serão incluídas em apêndice.
1.9. RESULTADOS E DISCUSSÃO
Trata-se de uma descrição factual dos resultados obtidos, baseando-se em
estatísticas, comparações, tabelas e gráficos construídos com os dados
recolhidos durante o trabalho.
Descreve detalhadamente os resultados das experiências de sucesso. As
experiências mal-sucedidas e as soluções erróneas devem ser, também,
incluídas, mas referindo-se-lhes de forma resumida. Estes tipos de
conclusões permitem abrir novos caminhos e explorar outras opções.
Uma vez apresentados os resultados obtidos (de uma forma lógica, que não
é, necessariamente, a cronológica), introduz-se a opinião pessoal sobre o
êxito ou fracasso do trabalho.
Deve ser-se objectivo, e adjectivar correctamente as opções, por forma a
atingir naturalmente as conclusões principais.
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 6
Tudo o que se afirmar deve ser verificável, quer pelo trabalho executado,
quer relacionando-o com trabalhos anteriores.
Quando se utiliza o trabalho de outrem, deve-se citá-lo (preferencialmente
através da fonte original) e apresentar as referências correctamente.
1.10. CONCLUSÕES
De forma resumida e clara deve ser feita a apresentação dos resultados
mais importantes e comparados com os objectivos iniciais enunciados na
introdução (o problema que foi proposto).
Os resultados obtidos podem não concluir o trabalho, mas ter contribuído
para a futura solução do problema. Neste caso indicam-se linhas de
investigação a serem seguidas para o efeito.
1.11. BIBLIOGRAFIA
Apenas as referências citadas no texto devem ser incluídas e enumeradas
por ordem alfabética.
Quando se cita uma passagem de um trabalho, tal deve ser feito de forma
correcta e referir a fonte utilizada. Deve usar-se de extremo cuidado para
garantir a exactidão das referências (mesmo a ortografia dos nomes).
O registo das referências deve ser executado de acordo com as regras
definidas em CITAÇÕES E REFERÊNCIAS BIBLIOGRÁFICAS.
1.12. ANEXOS
Incluir, sempre que existam, as listagens de programas, disquete/CD com
programas fonte e executáveis desenvolvidos, desenhos do projecto,
acetatos com diagramas de circuitos impressos, listagens e localização de
componentes, apresentação do projecto e outros elementos considerados
úteis.
2. ARTIGOS
A escritura de um artigo destina-se, fundamentalmente, à publicação em
revistas científicas. Pode, também, ser uma forma, utilizada pelos docentes,
para preparar o aluno para a escrita sintética necessária à divulgação dos
trabalhos científicos ou projectos.
São limitados em extensão (tipicamente seis páginas) e no seu layout, pelos
editores 1 .
A realização de um artigo científico obriga a responder, a anteriori, a um
conjunto de questões fundamentais:
Há co-autores? quais?
Quanto tempo é necessário para o completar?
Qual a revista a que irá ser submetido?
Qual a hipótese de ser aceite?
Quando será publicado?
1 Cada publicação (ou evento científico), estabelece as suas NORMAS DE REDACÇÃO.
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 7
Um artigo deve ser submetido a uma única revista (congresso, evento, …), e
seguir, fielmente, as normas estabelecidas para apresentação 2 . Apenas se
for recusado deverá ser submetido a um novo evento.
Ainda que para apresentação em Portugal, os artigos são, normalmente,
redigidos em inglês 3 . Neste caso, o sumário e as palavras-chave, deverão
ser escritos nos dois idiomas.
2.1. CO-AUTORES
Todos os autores devem ter dado contribuições explicitas para o trabalho,
quer de investigação, quer de escrita do artigo.
Se o número de co-autores for exagerado (i.e. mais de quatro), a sua
listagem deve ser limitada aos que se evidenciaram na realização do
trabalho, sendo os outros referidos, apenas, nos agradecimentos.
2.2. ESTRUTURA
A estrutura de um artigo científico é, genericamente, idêntico ao de uma
Trabalho de Fim de Curso, mas normalmente imposta aos autores pelos
editores.
As INSTRUÇÕES AOS AUTORES devem ser seguidas fielmente, para evitar que
o artigo possa, por uma questão meramente formal, ser recusado.
É, porém, comum, ser utilizada uma estrutura do tipo:
2.2.1. TÍTULO
A escolha do título é importante. Deve motivar a leitura e ser o mais curto
possível (máximo dez palavras).
2.2.2. NOME DO AUTOR
Título
Autor(es), Instituição e Endereço
Resumo
Palavras-chave
Introdução
Métodos e Técnicas
Resultados
Discussão (pode ser incluída na secção de resultados)
Conclusões
Agradecimentos
Bibliografia
O nome do autor deve seguir, imediatamente abaixo ao titulo. Inclui-se,
sempre, as Instituições a que pertencem e os seus endereços, para além
dos e-mail.
2
Em anexo encontra-se a norma de apresentação dos artigos para as disciplinas leccionadas pelo Grupo de
Controlo Automação e Robótica.
3
Também para a disciplina de Projecto de Fim de Curso se observa a redacção em inglês, enquanto que para a de
CIP, os artigos devem ser escritos em português.
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 8
No caso de artigos colectivos, os nomes não devem ser listados por ordem
alfabética, mas reflectir a importância das colaborações. Assim, o autor que
aparece citado primeiro será aquele que realizou a maior parte do trabalho
divulgado.
2.2.3. RESUMO
Tão, ou mais, importante que o título, é o resumo. Deve ser escrito o mais
cuidadosamente possível, para garantir o impacto sobre os leitores e motivar
a leitura do artigo. É escrito, apenas, quando o artigo se encontra concluído.
O número de palavras é, normalmente, estabelecida nas INSTRUÇÕES AOS
AUTORES. É, porém, comum uma limitação entre as 150 e as 250 palavras.
O resumo segue as regras apontadas para escrever NOTÍCIAS.
2.2.4. PALAVRAS-CHAVE
Também aqui as INSTRUÇÕES AOS AUTORES limitam, não apenas o número
(tipicamente de seis a dez), mas as próprias palavras a utilizar 4 .
Devem ser recolhidas no resumo apresentado e devem descrever, de forma
imediata, o conteúdo do trabalho realizado.
As palavras-chave seguem, de imediato, o resumo, podendo ser destacadas.
2.2.5. INTRODUÇÃO
Âmbito, objectivos e motivos que levaram à realização do trabalho. Inclui,
também, uma revisão bibliográfica não exaustiva.
A forma como o relatório foi estruturado e o que se espera transmitir em
cada secção, pode ser abordada de forma sintética. Deve ser evitada a
referência a conhecimentos perfeitamente consolidados.
2.2.6. MÉTODOS E TÉCNICAS
É a primeira parte do artigo a ser escrita. Ainda que de forma resumida
(atendendo à extensão dos artigos), segue os princípios já enunciados para
os Relatórios de Fim de Curso (ver parágrafo 1.8.).
2.2.7. RESULTADOS E DISCUSSÃO
Esta secção deve ser redigida seguindo as linhas filosóficas do parágrafo
1.9.
2.2.8. CONCLUSÕES
Siga as indicações apontadas no parágrafo 1.10.
2.2.9. AGRADECIMENTOS
Devem ser sintéticos, mas agradecer a todos os que contribuíram, de
alguma forma, para a realização do trabalho apresentado pelo artigo.
No caso de trabalhos financiados, tal deve ser sublinhado 5 .
4 Uma lista de palavras-chave é, normalmente, fornecida aos autores, para que escolham
entre as que se encontram listadas, as que pretende utilizar no seu artigo.
5 É normal existir, fornecida pela instituição financiadora, uma frase para incluir nesta secção
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 9
2.2.10. BIBLIOGRAFIA
As referências citadas no corpo do artigo devem ser incluídas e enumeradas
por ordem alfabética. Mas apenas as já publicadas. As não publicadas são
referidas no texto, incluindo o nome completo de quem forneceu as
informações (investigador ou instituição) e a data.
O registo das referências deve ser executado de acordo com as regras
definidas em CITAÇÕES E REFERÊNCIAS BIBLIOGRÁFICAS.
3. NOTÍCIAS
São curtas, tendo cerca de 200 palavras, nas quais se resume toda a
informação a transmitir. As notícias têm um prazo para serem escritas, pelo
que não existe uma segunda oportunidade para as escrever.
Baseiam-se em Quem, o Quê, Quando, Onde, Como e Porquê, (em inglês
os five W’s – who, what, where, when and why), devendo ser escritas dentro
do prazo da sua validade. O Quê, Quando e Como, deve constituir a maior
parte da notícia, sendo os pormenores acrescentados através do Onde e do
Quando.
Use frases curtas e escritas na voz activa – a experiência laboratorial mostra
que…, em vez de: verificou-se, pela experiência laboratorial realizada,
que…. Não use nunca a primeira pessoa.
Os RESUMOS, quer integrem os Trabalhos de Fim de Curso, quer sejam
redigidos para apresentação individualizada, devem ser considerados
como NOTÍCIAS.
4. ACETATOS
Devem ser simples, para rápida apreensão pela assistência, ter ilustrações e
caracteres a diferentes cores. Estas, escolhidas criteriosamente, para não
transformar a apresentação num arco íris, permitirão estruturar a
apresentação por codificação através da cor. Hoje, com o uso generalizado
dos video-projectores, em vez de retroprojectores, os acetatos podem ser
mais elaborados.
São apoios à apresentação oral. Não devem ser lidos integralmente.
Apresentam, apenas, as ideias básicas (por utilização de palavras-chave) a
transmitir.
A quantidade deve ser consistente com o tempo que se dispõe para a
apresentação. Muitos, obrigará a falar depressa, omitir alguns e esquecer as
ideias a transmitir. Poucos, sobrará tempo, obrigando a uma apresentação
discursiva, o que pode motivar a dispersão da assistência. Apresentam-se,
em média, três a quatro acetatos em cada dez minutos (2,5 a 3 min/acetato).
Para permitir uma leitura e compreensão quase que automática dos
conceitos a transmitir, deve seguir-se as seguintes regras:
Por cada acetato, que deve comunicar uma única ideia, o texto não
deve ter mais do que oito a 12 linhas com sete a dez palavras por
linha. Cada linha exprime um conceito da ideia a comunicar.
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 10
Tamanho dos caracteres (que dependem do tamanho da sala) deve
permitir uma leitura confortável da assistência. Para uma sala normal
(30 a 50 lugares) utiliza-se vulgarmente letras de 22/24 pt.
Usar cores para sublinhar diferenças e/ou semelhanças.
Cada acetato não deve conter mais do que um gráfico, quadro ou
tabela. Podem compor-se com frase elucidativas dos pormenores a
realçar.
Uma figura vale por mil palavras, mas não coloque várias no mesmo
acetato, pois cada uma transmite, normalmente, uma ideia. Podem
compor-se com frase elucidativas dos pormenores a realçar.
Use animação ou filmes para clarificar ou mostrar os pormenores mais
importantes do trabalho. Esta facilidade está, actualmente, disponível
pela utilização de video-projectores e computador. Esta capacidade,
se explorada, reduz, porém, o número que acetatos a utilizar na
apresentação.
Como meio de apoio visual (cada vez mais audiovisual devido à utilização de
computadores e video-projectores), há que ter em atenção a imagem a
transmitir.
4.1. IMAGEM
Promove a consistência e qualidade... por harmonização… gráfica e visual.
A identidade será tanto mais forte e eficaz, quanto mais simples, directa e
consistente for a imagem.
A excelência, quer a nível global quer a nível de cada detalhe, deve constituir
um modo de estar para o IST. Desde a originalidade da investigação às maiores
realizações académicas, passando pelo grafismo e impressão dos seus
relatórios... todos estes aspectos devem expressar a cultura do IST.
(In Manual de Harmonização de Imagem IST - 1996)
Por tal motivo, os acetatos, devem seguir as normas estabelecidas pelo
Manual de Harmonização de Imagem do IST.
A figura junta mostra o aspecto geral (e informações úteis) do layout a usar
para as apresentações referentes ao Instituto Superior Técnico.
80
68
59
25
25
INSTITUTO
SUPERIOR
TÉCNICO
Secção
de Sistemas
140
Título
Sub-título
Área para introdução (preferencial) de textos e
imagens em letra tipo Times, com títulos em Gill
Sans ou Arial, tamanho suficiente para permitir a
leitura.
Os textos devem ser alinhados à esquerda.
Figura 4 – Layout recomendado para acetatos
Rui Loureiro - 2004 Projecto de Fim de Curso
25
Os títulos (36pt.,
negrito) e os subtítulos
(24pt., simples), são
grafados em letra tipo
Gill Sans ou Arial, letras
maiúsculas e
minúsculas, alinhados à
esquerda.
O nome da Secção de
Sistemas é impresso a
azul escuro, Pantone
287, conforme a
ilustração, a 11pt.,
negrito, em letra tipo Gill
Sans ou Arial, letras
maiúsculas e
minúsculas, alinhado à
esquerda.

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 11
4.2. ESTRUTURA
A estrutura da apresentação com acetatos segue o esquema indicado pelas
figuras. Em baixo à direita, entre parênteses rectos, sugere-se o número de
acetatos conveniente, para uma apresentação de 30 minutos.
INSTITUTO
SUPERIOR
TÉCNICO
Secção
de Sistemas
INSTITUTO
SUPERIOR
TÉCNICO
Secção
de Sistemas
INSTITUTO
SUPERIOR
TÉCNICO
Secção
de Sistemas
INSTITUTO
SUPERIOR
TÉCNICO
Secção
de Sistemas
Título do Trabalho
Nome do(s) autor(es)
Nome do Apresentador
Afiliação
Trabalho orientado por: Prof. ….
Introdução
Justificação do tema do trabalho
Enquadramento
Objectivos
Resultados
(resumidamente)
Gráficos
Quadros comparativos
Outras indicações necessárias
Trabalho futuro
Projectar o trabalho no futuro
Como pode ser completado
[1 acetato]
Figura 5 – Acetatos de abertura
[2 a 3 acetatos]
[3 a 4 acetatos]
Figura 6 – Acetatos de apresentação
[1 acetato]
Figura 7 – Acetatos de encerramento
Rui Loureiro - 2004 Projecto de Fim de Curso
INSTITUTO
SUPERIOR
TÉCNICO
Secção
de Sistemas
INSTITUTO
SUPERIOR
TÉCNICO
Secção
de Sistemas
INSTITUTO
SUPERIOR
TÉCNICO
Secção
de Sistemas
INSTITUTO
SUPERIOR
TÉCNICO
Secção
de Sistemas
Agradecimentos
Agradecimentos a pessoas e instituições.
A existência de apoios financeiros é
referida de forma nominativa.
[1 acetato]
Métodos e Técnicas
(resumidamente)
Como se realizou
Onde foi realizado
O que se obteve
Conclusões
Que se obteve dos resultados
Como enquadra o trabalho
...
Discussão
(facultativo)
[4 acetatos]
[1 a 2 acetatos]
Esta acetato final, deve motivar a sessão
de perguntas e respostas e manter-se
exposto até ao seu encerramento.
[1 acetato]

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 12
4.3. OUTRAS INFORMAÇÕES
A estrutura da apresentação pode variar, adaptando-se ao trabalho
realizado.
É dada grande liberdade de concepção para os acetatos individuais, desde
que as referências obrigatórias (logotipo do IST e indicação da secção)
estejam presentes, para preservar a imagem da Instituição.
Todos os acetatos devem ser identificados. Para além do primeiro, cuja
função principal é a apresentação do trabalho e indicação da autoria, os
restantes devem sê-lo em rodapé. À esquerda o nome do(s) autor(es), a data
e o local (opcional) onde se faz a apresentação. À direita, o título do trabalho
e a paginação. Utilizar letra tipo Gill Sans ou Arial, 8/10 pt., letras maiúsculas
e minúsculas.
Alberto Moreno e Tiago Norte - Março 2004 - Lisboa Controlo de Processos por Visão - 12
5. CARTAZES
Figura 8 – Identificação dos acetatos em rodapé
O cartaz (genericamente designado por painel ou poster), é um dos
elementos de avaliação da disciplina de Projecto de Sistemas I e II.
Pretende-se que possam ser exibidos alguns dias antes das apresentações
e que se mantenham em exposição, por toda a semana que se seguir.
Servirão, também, para apresentação em eventos, que durante o ano lectivo
seguinte tenham lugar. É uma forma de mostrar o que se produz, em termos
científicos e de ensino no DEM e, mais especificamente, no Grupo de
Controlo Automação e Robótica.
Um POSTER deve ser :
ATRACTIVO – mas contribuindo para veicular, de forma
eficiente a mensagem cientifica.
ORGANIZADO – o tema é focado de forma simples e
posicionado em lugar de máxima
visibilidade.
DE FÁCIL LEITURA – estando colocado numa parede, deve
permitir a leitura a uma distância mínima de
1,5 m.
Não esquecer que a estrutura, organização, design, clareza e apresentação
cuidada, são essenciais para o sucesso dum cartaz.
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 13
5.1. ESTRUTURA
5.1.1. LÍNGUA
Um poster, ainda que para apresentação interna, deve, tal como os artigos
científicos e os sumários, ser escrito em língua inglesa.
5.1.2. DIMENSÕES
Para garantir a normalização dimensional, com os cartazes utilizados por
outras instituições, utiliza-se 100cm (altura) x 70 cm (largura).
5.1.3. SUPORTE
Para permitir a exposição suspensa, o cartaz deve ter um suporte rígido.
Utiliza-se, vulgarmente, K-line de 4/6 mm de espessura.
5.1.4. LOGOTIPO DO IST
Garantindo a imagem do IST, o logotipo deve ser colocado no canto superior
esquerdo do cartaz, com a indicação do Departamento (i.e. DEM), Instituto
(i.e. IDMEC) ou secção (i.e. Secção de Sistemas), de acordo com as normas
estabelecidas pelo Manual de Harmonização de Imagem.
5.1.5. TÍTULO
Com letras maiúsculas tipo Times New Roman (60-pt negrito). Não mais de
dez palavras. Centrado.
5.1.6. AUTORES
Inscritos sob o título, grafados a letra tipo Times New Roman (33-pt negrito)
em maiúsculas e minúsculas. Utilizar uma única linha centrada.
Apenas o nome próprio e o apelido, serão impressos por extenso. Uma
inicial intermédia poderá ser utilizada caso possa haver ambiguidade.
5.1.7. FILIAÇÃO
Em letra tipo Times New Roman (24-pt itálico) maiúsculas e minúsculas,
centrado, deve escrever-se o endereço completo da instituição que acolhe os
autores. Caso existam, os e-mail destes devem ser adicionados.
5.1.8. RESUMO
Título em letra tipo Times New Roman, 24-pt negrito, alinhado à esquerda.
Texto em letra tipo Times New Roman de 24-pt, maiúsculas e minúsculas,
justificado, com o máximo de 100 palavras.
Condensado ao mínimo deve incluir como e onde o trabalho foi realizado.
5.1.9. BIBLIOGRAFIA
Apenas as referências, directamente citadas no texto, são listadas
alfabeticamente, pelo nome do primeiro autor. As regras de inscrição
bibliográfica são idênticas às utilizadas nos artigos científicos.
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 14
Título em letra tipo Times New Roman, 24-pt negrito, maiúsculas, centrado.
Restantes linhas devem ser indentadas.
5.1.10. CORPO
O texto deve ser impresso a duas colunas, sempre que possível, sem
sacrificar a clareza da mensagem ou a imagem do cartaz.
O tipo de letra a utilizar é deixada à imaginação do autor(es). O tamanho de
24pt, maiúsculas e minúsculas, deve ser escolhido para permitir a leitura a,
no mínimo, 1,5 m.
Os parágrafos são justificados, usam espaçamento a uma linha e não são
indentados. Usa-se uma linha em branco para separar parágrafos.
5.1.11. AGRADECIMENTOS
Título em letra tipo Times New Roman, 24-pt negrito, maiúsculas, centrado.
Corpo em letra tipo Times New Roman 18-pt, maiúsculas e minúsculas,
centrado.
5.2. CONTEÚDO
5.2.1. INTRODUÇÃO
Breve, referindo apenas os tópicos do trabalho realizado. A introdução não é
um amontoado de teorias e equações. Pode utilizar frases curtas (bullet
points).
5.2.2. OBJECTIVOS
Devem ser realçados e apresentados em frases curtas.
5.2.3. TRABALHO REALIZADO
Textos resumidos. Devem ser utilizados desenhos e esquemas.
5.2.4. RESULTADOS
Utilizar tabelas, figuras ou esquemas para apresentar os resultados obtidos
experimentalmente.
5.2.5. CONCLUSÕES
Não devem incluir discussão, apenas indicar as ideias principais, a serem
extraídas dos resultados encontrados.
5.3. GRAFISMO
5.3.1. FIGURAS
Devem ser posicionadas o mais perto possível da referencia que lhe é feita
no texto.
As fotografias e figuras devem ser coloridas, porém preparadas para
impressão em níveis de cinzento.
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 15
5.3.2. TABELAS
Não se utilizam linhas verticais para
separar as colunas, apenas as linhas
horizontais de separação das entradas.
O título deve ser sublinhado e utilizar
letras do tipo Times New Roman de 18-pt,
maiúsculas e minúsculas, centrado.
6. APRESENTAÇÕES ORAIS
Uma prova pública, apesar de interna, é realizada em ambiente
relativamente formal. Trajar, pois, de acordo com a ocasião.
Deve falar-se claramente, devagar, em voz alta (para garantir a audição
sobre o ruído de fundo dos ouvintes) e olhando directamente para a
audiência. O recurso a notas escritas deve ser o mais reduzido possível.
Não ultrapassar o tempo atribuído à apresentação. Ter-se-à oportunidade,
na sessão de perguntas e respostas, de voltar aos temas que tenham ficado
menos explícitos na apresentação.
O poster pode ser utilizado como apoio à sessão de perguntas e respostas.
Deve, por isso, distribuir-se, pela audiência, uma cópia (A4) a preto e branco.
Também o resumo do trabalho deve estar disponível à assistência.
Durante a sessão de perguntas e respostas, deve analisar-se as perguntas
recebidas e dar respostas curtas, concisas e objectivas, mas em perfeita
ligação com a comunicação efectuada. Não sustentar discussões
discordantes. Neste caso convidar o interlocutor para uma conversa no fim
dos trabalhos.
7. CITAÇÕES E REFERÊNCIAS BIBLIOGRÁFICAS
A forma de registar as referências depende do estilo da publicação e das
suas regras, devendo ser seguidas no mais ínfimo pormenor.
Indicam-se, seguidamente, as regras para citações e referências
bibliográficas a utilizar nos trabalhos das disciplinas leccionadas pelo Grupo
de Controlo Automação e Robótica, nomeadamente Projecto de Sistemas I e
II e Controlo Integrado da Produção, que seguirão o SISTEMA HARVARD
(também designado por Sistema Nome-e-Ano).
7.1. SISTEMA HARVARD
Table heading underlined and centred
Xxxx Xxxx Xxxx Xxxx
X X XX
XXX X XX XX
X XXX XX XXX
Na secção de Bibliografia, a listagem dos autores deve ser feita por ordem
alfabética. Quando o autor, possui várias publicação referidas, estas serão
inscritas por ordem cronológica. Se inscrever mais do que uma publicação,
do mesmo autor e ano, deve distinguir as referências por letras minúsculas a,
b, c, etc.
Exemplos:
ABREU, R. (2003), …
BAKER, Gold (1998), …
BAKER, Richard (2000), …
CARVALHO, H. (1999), …
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 16
CARVALHO, H. (2001), …
ESTRELA, E., SOARES, M.A., e LEITÃO, M. J, (2003), …
MADEIRA, A.C. e ABREU, M.M., (2004), …
RICARDO, D. (2003a), …
RICARDO, D. (2003b), …
RICARDO, D. (2003c), …
A vantagem de se adoptar este sistema, em relação a outros (i.e. Vancouver,
que utiliza numeração sequencial), é o poder-se adicionar ou apagar citações
ou referencias dos textos, sem alterar a secção Bibliográfica. Há, também,
uma imediata identificação das referências.
7.2. CITAÇÕES NO TEXTO
Ao citar uma referência, deve indicar o nome do autor e o ano da publicação.
Se citar mais do que uma publicação, do mesmo autor e ano, deve distinguir
as referências, adicionando ao ano letras minúsculas. Publicações com dois
autores, devem ser indicadas com ambos os nomes seguidos do ano. Se as
referências tiverem mais do que dois autores, será indicado apenas o nome
do primeiro autor seguido de et al.
Exemplos:
Ricardo (2003b) apresentou …
De acordo com Madeira e Abreu (2004), concluímos….
Tal como descrito (Estrela et al.,2003), sugere-se …
7.3. REGRAS DE LISTAGEM BIBLIOGRÁFICA
Há diversas regras sobre a forma como as citações feitas no texto devem ser
listadas na Bibliografia. A inscrição depende do tipo de publicação.
Listam-se, seguidamente, os esquemas de inscrição que deve utilizar.
7.3.1. ARTIGOS
Autor(es) (apelido por extenso [virgula], inicial do nome próprio [ponto]
separação entre autores feito por virgula) [espaço] Ano da publicação (entre
parênteses) [vírgula] Título do artigo [virgula] Nome da publicação (em
itálico) [espaço] número do volume (em negrito) [dois pontos] páginas
referidas [ponto].
Exemplo:
Charlie, P. (1985b), Controlling by Remote Sensing, Journal of Process
Control 66:125-131.
7.3.2. CAPÍTULOS DE LIVROS
Autor(es) (apelido por extenso [virgula], inicial do nome próprio [ponto]
separação entre autores feito por virgula. Utilização do separador [e] para o
último autor) [espaço] Ano da publicação (entre parênteses) [vírgula] Título
do capítulo [ponto] [In] Título do livro (em itálico) [virgula] Nome(s) do
editor(es) [ed(s).] [vírgula] [pp.] páginas referidas [ponto] Entidade editora
[vírgula] Local (cidade) [vírgula] e país de publicação (siglas) [ponto]
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 17
Exemplo:
MADEIRA, A. e CARDEIRA, M. (1954), Referências Bibliográficas. In
Comunicar e redigir trabalhos científicos, R. Dias (ed.), pp. 53-58. Academia,
Lisboa, PT.
7.3.3. LIVROS
Autor(es) (apelido por extenso [virgula], inicial do nome próprio [ponto]
separação entre autores feito por virgula. Utilização do separador [e] para o
último autor) [espaço] Ano da publicação (entre parênteses) [vírgula] Título
do livro (em itálico) [ponto] Entidade editora [vírgula] Local (cidade) [vírgula]
e país de publicação (siglas) [ponto] Número total de páginas [pp.]
Exemplo:
MADEIRA, A. e CARDEIRA, M. (1954),Comunicar e redigir trabalhos
científicos. Academia, Lisboa, PT. 155 pp.
7.3.4. ACTAS DE CONFERÊNCIAS
Autor(es) (apelido por extenso [virgula], inicial do nome próprio [ponto]
separação entre autores feito por virgula. Utilização do separador [e] para o
último autor) [espaço] Ano da publicação (entre parênteses) [vírgula] Título
do trabalho [ponto] [Actas da Conferência (ou Proceedings of)] Nome da
conferência (em itálico) [virgula] Nome(s) do editor(es) [ed(s).] [vírgula] Local
(cidade) [vírgula] e país (siglas) onde foi realizada a Conferência [ponto] [pp.]
páginas referidas [ponto]
Exemplo:
Pereira, A. et al.(2000), Remote Control in Industrial Processes. Proceedings of
Industrial Processes’2007: 9th Portuguese Conference on Remote Control,
Barrera, C. (ed.), Castelo Branco, PT. pp. 4-6.
7.3.5. DISSERTAÇÕES E TESES
Autor (apelido por extenso [virgula], inicial do nome próprio [ponto]) [espaço]
Ano de apresentação (entre parênteses) [vírgula] Título completo do trabalho
(em itálico - incluindo subtítulos se existir) [ponto] Grau (Tese de
Doutoramento, Dissertação de Mestrado) [ponto] Instituição [vírgula] e Local
(cidade) [vírgula] e país onde foi apresentada [ponto] número de páginas
[pp.]
Exemplo:
Kong, X. (1999), Incorporating Landscape Pattern Features in a Spatial
Harvest Model. Ph.D. Thesis. University of British Columbia. Vancouver,
CAN. 121 pp.
7.3.6. INTERNET
A Internet é um meio de pesquisa bibliográfica importante, logo não pode ser
esquecida como forma de consulta em trabalhos científicos. Porém, sendo
um ambiente extremamente dinâmico, os endereços, onde se encontram os
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 18
trabalhos a referenciar, desactualizam-se rapidamente. Por este motivo, a
Bibliografia, obtida por pesquisa na Internet, só deve ser utilizada quando
não se teve acesso a versões impressas, caso contrário devem ser estas as
referidas.
a) Artigos científicos on line:
Autor(es) (apelido por extenso [virgula], inicial do nome próprio [ponto]
separação entre autores feito por virgula) [espaço] Data do documento –se
existir - (entre parênteses) [vírgula] Título do trabalho [virgula] Título da
publicação (em itálico) [espaço] número do volume (em negrito) [dois
pontos] páginas referidas [ponto] [Disponível em: ]
[ponto] [Acesso em:] [ponto]
b) Homepage:
Autor(es) (apelido por extenso [virgula], inicial do nome próprio [ponto]
separação entre autores feito por virgula) [espaço] Título [ponto] Informações
complementares [ponto] [Disponível em: ] [ponto] [Acesso
em:] [ponto]
8. ANEXOS
Os exemplos que se juntam, ainda que não sigam exactamente as regras
definidas por estas normas, o que não será possível nos trabalhos a realizar
futuramente, mostram, de uma forma geral, o modo como se devem
apresentar, quer posters quer papers.
PAPER 1
PAPER 2
PAPER 3
AUTOMATIC CREATION OF SIMULATION MODELS FOR FLOW
ASSEMBLY LINES
WEB BASED SUPERVISION OF REMOTE UNITS
INDUSTRIAL SENSORS FOR GUIDING AN AUTONOMOUS VEHICLE
Rui Loureiro - 2004 Projecto de Fim de Curso

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 19
POSTER
IDMEC
FPIAA (Find Persons in Atlas Areas)
Abstract: The main objective of this system is to find persons inside the ATLAS area, in case of
accident, or if someone is still inside when an experiment is about to begin. As such, both software
and hardware issues must be resolved. ATLAS presents a unique working environment, both in
environment and in requirements.
In the hardware issue, only the solution based on volumetric ultrasonic sensors appears to be feasible,
due to restrictions with other volumetric sensors and high cost of non-volumetric alternatives. A field
bus will connect these sensors to a computer to process the data.
Also software will be developed to process hardware input, visualization and alarm generation.
The prototype has the following abilities :
• Detect position of persons as indicated by volumetric sensors;
• Generate alarms when a person disappears. That happens when sensors are detecting
someone, and suddenly both that sensor and nearby sensors stop detecting for a given amount
of time. That could signal a problem with that person.
This is a viability study. As such, it’s unclear whether a useful system can be produced, and if so,
whether it can be produced within budget. This is due to the fact that the environment and
requirements are unique.
Carlos Cardeira 1 , Amélia Maio 2 , Gianpaolo Benicasa 3
1
Instituto Superior Técnico, Technical University of Lisbon
Mechanical Engineering Department, IDMEC-GCAR
Av. Rovisco Pais, 1049-001 Lisboa, Portugal
e-mail: {xxx, yyyyy, zzzzz}@dem.ist.utl.pt
2
LIP Lisboa
Av. Elias Garcia 14, 1º 1000-149 Lisboa, Portugal
e-mail: ameliamaio@werkygtdr.pt
3
CERN
CH-1211 Genève 23 Switzerland
e-mail: g.benicasa@sw.ddeuvgft.com
BIBLIOGRAPHY
Atlas Technical Design Report, Cern Report Number ATLAS-TL13, January 1999
G. Benicasa, “Equipment fault report and safety: a proposition”, EDMS:ATC-TY-EN-0001
ACKNOWLEDGEMENT
This research is partially financed by the FCT through the program POCTI - Unidade 46 - Linha 3,
subsidized by FEDER.
This work was partly supported by CERN (IDMEC grant nº PL208).
This proposal addresses CERN’s person surveillance needs inside the
ATLAS area.
During the maintenance periods, tens of specialists enter the cavern
where the system is located for verifications and repair work. The
specialists need to enter the ATLAS itself and other exiguous areas not
visible from the outside. Sometimes it is even necessary to crawl some
distance to the area of interest. The topology of the working environment
is complex making very difficult the work of rescue teams in case of
accidents such as fire or cryogenic liquid spills.
The need to know where people are is essential to prevent fatal
consequences if any accident ever occurs.
This work proposes the study and implementation of a prototype of a
data acquisition system that can remotely show the positions of persons
in the monitored areas. This prototype if successful in a controlled
environment can be tested in the ATLAS environment so that a
production system can be designed.
Architecture overview
Each volumetric sensor is connected to the computer hosting the monitoring software. The prototype has only a limited number of sensors connected only to show the
concept. The monitoring software picks up the signals sent from the sensors, and displays them in a graphical interface showing the physical space occupied by the monitoring
system. The software keeps track of incoming signals and remembers them in order to activate alarm signals to the operator when a contact is lost. The notion of a lost contact
is a time-out on a signal.
Software
The monitoring application displays graphically the monitored area. This area is organized by nodes, each one being a monitored zone. Each zone corresponds to a sensor. When
a signal is being received from that zone the application shows a person icon over the node.
The application generates alarms when a given contact is not followed by another contact either in the same zone or any adjacent navigable zone, in a given amount of time.
The software takes an optimistic approach. If a contact is lost before the timeout and another adjacent contact overlaps the first, no alarm is generated. It is assumed that the
second contact is responsible for giving out the alarm if the first one corresponds to an injured person.
The model of the hypothetical area to be monitored will be simple enough to fit in a normal desktop computer screen.
sensor
sensor
sensor
sensor
Rui Loureiro - 2004 Projecto de Fim de Curso
sensor
sensor
Workstation

IST - DEM – Secção de Sistemas Normas de redacção e apresentação - 20
BIBLIOGRAFIA
ESTRELA, E., SOARES, M.A., e LEITÃO, M. J. (2003), Saber Escrever Saber Falar:
Um guia completo para usar correctamente a língua portuguesa, Dom Quixote,
Lisboa.
MADEIRA, A.C. e ABREU, M.M. (2004), Comunicar em Ciência: como redigir e
apresentar trabalhos científicos, Escolar Editora, Lisboa.
RICARDO, D. (2003), AINDA BEM QUE ME PERGUNTA: manual de escrita
jornalística, Editorial Notícias, Lisboa.
WILSON, A. (org.) (2001), MANUAL DE COMUNICAÇÃO EM CIÊNCIA: Como transmitir
num minuto ou numa página o trabalho de anos, Tradução de Tânia Rocha,
Editorial Replicação, Lisboa.
Rui Loureiro - 2004 Projecto de Fim de Curso

AUTOMATIC CREATION OF SIMULATION MODELS FOR FLOW ASSEMBLY
LINES
João Weinholtz†, Rui Loureiro‡, Carlos Cardeira†, João M. Sousa†
†Instituto Superior Técnico, Technical University of Lisbon
Dept. of Mechanical Engineering, GCAR - IDMEC
Av. Rovisco Pais, 1049-001 Lisboa, Portugal
joao.weinholtz@netcabo.pt, {carlos.cardeira, jmsousa}@ist.utl.pt
‡Bombardier Transportation Portugal, SA
Rua Vice-Almirante Azevedo Coutinho , nº 1, 2700-843 Amadora, Portugal
rui.loureiro@pt.transport.bombardier.com
Abstract: This paper presents a new software tool for automatic creation of simulation
models for flow lines. The tool was developed in a general way. The tool was applied to the
production flow line at the rolling stock Company Bombardier Transportation Portugal, SA,
in Amadora, in order to develop its simulation model. Information regarding manufacturing
philosophies, flow assembly lines, production scheduling, and software tools for the model
creation are required to perform this task. The paper mainly focuses on the model creation
process and the productivity gains generated by this work. Copyright © 2004 IFAC
Keywords: Process simulators, production systems, scheduling, simulation.
1. INTRODUCTION
New manufacturing philosophies points to production as
the central area of the manufacturing process. Note that
production is supported by many other service functions
in order to timely deliver high-quality, low-cost,
functional products to customers, see Pinedo (2002). The
major concerns of the order/project management are then
process organization, resource optimization and
throughput time reduction according to vision and
objectives of the company.
The dynamic strategies of corporations, especially the
ones that have to lead with long lead-time products, are
dealing with a strong increase of management
complexity, since processes and information must be
adjusted quickly and consistently. Currently, these
adjustments to changes have not been done in an
efficient way; the costs of changes are usually high.
Therefore, the low adaptation of enterprises to the
constraints of the market resources is not allowing the
optimization of processes and is degrading production
costs.
Several software solutions are commercially available to
this optimization, but they normally are focused on the
sequence generation and/or line balancing, disregarding
the optimization of production processes and the
dynamism of the companies.
Due to the high costs associated with the revision of a
manufacturing process (a methods team would spend
weeks or months to redesign a running process and the
double of the time to issue all required documentation)
process optimization is only verified once – in the initial
phase of layout design and aggregate documentation.
Thus, the optimization process is done by local subprocess
improvement with the goal of reducing the
execution time of individual tasks, ignoring completely
the dynamic philosophies linked with company main
lines.
In order to achieve optimized solutions at reduced cost, it
is imperative to develop algorithms to be implemented in
some standard software.
This paper presents the development of software tools to
simulate and optimize flow assembly lines. The
presented tool allows the inclusion of methods staff
expertise. This know-how allows a fast dynamic
reconfiguration of the assembly scheduling, a fast
response to shortages in assembly line or equipment

malfunctions and an efficient adaptation to changes in
the company objectives.
The study of flow production lines is a very complex task
due mainly to the huge number of variables to handle
(Pinedo and Chao, 1999). The developed work started by
analyzing an existing production line. A deep and
continuous communication with the methods team was
required for acquiring data and learning in detail the
implementation of the production line.
The key point in a flow assembly line is the production
schedule. The scheduling solutions for production were
optimized based on standard techniques, namely the
Shifting Bottleneck Heuristic (Pinedo, 2002). These
solutions were developed recurring to the software
MatLab. The obtained scheduling is stored in a database
and becomes the input necessary for the model creation.
These data is translated to Arena using Visual Basic, to
simulate, validate and test the obtained production
simulation models. Note that the work is general enough,
such that the developed models can simulate different
types of large-scale products, such as rolling stock
material, planes or armored vehicles.
Classically, simulations models are built to represent the
reality. As so, the ideal model should allow the
simulation of unforeseen difficulties and adapt itself to
new environments. A simulation, beyond representing
the reality, can also be used to study the model responses
to chosen sequences of events. The main goals of the
developed work were then to obtain a solution for the
scheduling problem and to define the risk of the solutions
found. To achieve these objectives the following steps
were performed:
1. Analysis of flow assembly lines and identification of
their constraints.
2. Definition of a data structure to store the production
schedule for simulation purposes.
3. Development of a software tool for automatic
creation of simulation models of a given production
schedule.
4. Application to the flow assembly line of the train
manufacturing process implemented at Bombardier
Transportation SA – Amadora.
5. Analysis of obtained results.
This article is organized as follows. Section 2 presents
some software simulation tools and the reasons to choose
a special one. Section 3 describes the characteristics of
the developed software tool, presenting both the objects
of the tool and the flow assembly lines specifications and
special characteristics. The detailed description of the
developed software tool and the justification for some
options that were made are presented in Section 4. A
case study and its production scheduling are described in
section 5, and some conclusions are drawn in section 6.
2. SOFTWARE SIMULATION TOOLS
The simulation of industrial assembly lines has been
done by different methodologies, especially by those that
are computer aided. Different software tools can be
found for discrete or continuous event systems exist.
Due to the industrial focus of simulation software
houses, some difficulties arise in finding information
about the features of commercial available tools.
Hssain (2000) presents some solutions to flux simulation.
Moreover, there are different software simulation and
scheduling tools available like Arena (Kelton et al.,
2003), Witness, Automod, Asprova, or Jobboss, for
which their features were summarily studied. Russo and
Vicente (2003) performed a comparative study of those
software tools based on learning easiness, process
adaptation, graphic features and cost aspects, as
presented in Table 1.
Table 1: Software tools comparison
learning
easiness
process
adaptation
continuos
process
graphic
features
cost
ARENA D A C A C
AUTOMOD C A C A D
EXTEND B B A B A
PROMODEL B B D B D
SIMPLE ++ C C D C E
TAYLOR B C D B B
WITNESS C A C B D
The characteristics that are more relevant for the
presented work are process adaptation and the
visualization facility translated in the graphic features.
By observing Table 1, it is easily concluded that both
Arena and Automod are suitable to the simulation
purposes of this paper. As Arena is less expensive, and
moreover a license under special conditions for research
and development was possible to be bought, it was the
software chosen for simulation of the production line.
3. CHARACTERISTICS OF THE SOFTWARE TOOL
This section presents the description of the basic
features, in terms of functional characteristics to allow
the development of simulation models.
3.1 Objects of the software tool
The objects of the software development tool are the
following.

Entities – are the dynamic objects for simulation.
They can be created, used through the system and
deleted when they no longer necessary for the
simulation. They are abstract representations of the
objects to be processed in the system.
Attributes – are each characteristic of an entity. An
entity can contain several different characteristics at
same time.
Variables – are defined as global for a specific
system, and have read/write access by all the
entities.
Resources – represent any need, such as a worker, a
machine, etc. of a task. The resources have limited
capacity, can be used in any section of the model
and can be used by any entity.
Queues – are entities that request a resource in use
by other entity. The entities must wait in the queue
until the resource is released.
Arena
Macros
Visual
Basic
Automatic creation of
simulation model
Macros
Fig. 1: Creation of the simulation model.
In order to build a simulation model automatically it is
necessary to make the connection between a production
schedule using the Shifting Bottleneck Heuristic (stored
in Excel) and Arena. The communication is established
using a Visual Basic program, which receives the
necessary information and creates the simulation of the
production line in Arena.
3.2 Specifications and special characteristics
During the process analysis important constraints were
taken into account:
Working stations may share resources
Tasks may have predecessors
Assembly lines have the ability to produce vehicles
of different types
Different tasks can be executed simultaneously in
the same working station, but at different locations
Task assembly times follow a probabilistic
distribution
Task times can have large variations.
These specifications were all implemented in the
software tool to create simulation tools. It should be
stressed that he cooperation of workers and production
experts was fundamental for the determination of the
characteristics of the assembly line and their respective
constraints.
4. SOFTWARE TOOL FOR MODEL CREATION
The software tool developed for the simulation of
production lines is at the moment implemented for
Flexible Flow Shop configurations (Pinedo, 2002). Any
production schedule can be modeled and simulated by
Arena using the developed tool.
The model manages all the existing resources and tasks,
creating sequences and attributes characteristics to them.
Each task can be described as independent, i.e., it does
not need to follow a sequence, and can be part of
different sequences. Several variables must be created,
namely: vehicle type, vehicle type comparison, station
occupation control and task execution identification. The
software tool also creates the processing models
described next.
4.1 Entity creation
Each entity represents a “vehicle”, which receives all
tasks and resources required, and transport them until the
end of the manufacturing process. The entity must follow
the tasks defined in the production schedule, which are
accomplished in the given station. At any instant the
entity must contain the work in progress of the process.
This module determines also the first stations of the
routing to be followed by the entity, holding it in case the
destination station is not free. An example of the Arena
aspect of an entity is given in Fig. 2.
Fig. 2: Entity creation and routing indication.
4.2 Start of an assembly station
Assembly stations are independent amongst them. These
stations transform the arriving entity and process it. The

entity type is verified and routed to the task sequence
defined for the station. The number of teams and its
location in the station are defined and included into the
entity. Also task works are attributed to the entity. The
assembly station can receive different kinds of entities
and processes them sequentially. An example of an
assembly station is given in Fig. 3.
Fig. 3: Example of an assembly station with 4 types of
entities to process.
4.3 Tasks
The objective of a task is to use the respective resources
taking a certain time according to its requirements. Some
tasks may be dependent of others (precedents) to be
initialized. Only the precedent tasks processed in the
same station are verified before the initialization of a
task.
When an entity arrives at a certain task, the availability
of resources must be verified. If the resources are not
available, the entity is retained until they are at disposal.
The resources are retained by that task during a certain
time, and are released when this time elapses. After the
task conclusion, the entity is routed to the next task or to
the end of the station. The task formation in Arena is
shown in Fig. 4.
Fig. 4: Task formation.
4.4 Closing of the assembly station
When an assembly station is closing, the leaving entities
represent an assembled product or part of it.
This module is used to aggregate all assembled parts of
the product in just one entity that represents all work in
process incorporated in the tasks processed before. This
last entity is then routed to the end of the module, where
is retained until the next station is available to receive it.
Transport of entities between stations is made by a single
resource. If the transportation means are not available,
the entity remains at the end of the station waiting for its
availability.
Each closing assembly station can concatenate up to 25
teams (processes) into one single entity. Is also in this
module that some statistical data can be stored for later
analysis. An example is given in Fig. 5.
Fig. 5: Example of a closing assembly station module
concatenating 2 teams.
4.5 End module
After an entity had passed through all assembly stations
it is routed to the end module (were its throughput time is
computed) and disposed, see Fig. 6.
Fig. 6: Process ending module.
5. CASE STUDY
In this paper, the case study for software validation is the
production line of rolling stock vehicles of the CP2000
type, manufactured at Bombardier Transportation
Portugal SA, Amadora. The flow assembly line is
producing a train of four different vehicles, as shown in
Fig. 8.

Fig. 8: The CP2000 train formation.
5.1 The CP2000 assembly line
The assembly line is unique and processes all vehicles
simultaneously at the same bit-rate. Each vehicle has its
own assembly tasks but the assembly line responds well
to the different solicitations. Eight workstations, with
four locations each, form the flow assembly line to built
the train, see Fig. 9.
Entrada
Saída
Pré-Montagem
Bogies
Estação 650
EA
Estação 620 Estação 625 Pré-Montagem
Fluxo de Trabalho
IA IB
Estação 640
Fig. 9: Assembly line implemented.
5.2 Sequence of workstations
EB
Estação 630
Ensaio estanqueidade
The assembly line is composed by five workstations
(numbered 620, 625, 630, 640 and 650) and the station
640 is divided into four independent stations. The
workstation 650 does the concatenation of the four
vehicles for train formation. The sequence of
workstations is presented in Fig. 10.
Station 640 (1)
Vehicles EB
Bit Rate 12 days
Station 640 (2)
Vehicles IB
Bit Rate 12 days
Station 620
All vehicles
Bit Rate 3 days
Station 625
All vehicles
Bit Rate 3 days
Station 630
All vehicles
Assembly tasks
Duration 2 days
Tightness test
Duration 1 days
Bit Rate 3 days
Station 650
Vehicle concatenation EA
Station 640 (3)
Vehicles IA
Bit Rate 12 days
Station 640 (4)
Vehicles EA
Bit Rate 12 days
Fig. 10: Sequence of working stations.
A bottleneck is found in workstation 630 due to the
tightness tests.
5.3 Working locations
The team working locations vary depending on the
workstation. Teams can have 1, 2 or 4 workers each.
Working locations by station are determined according
the following rules:
Vehicle interior
o Salon – Max 2 teams of 2 workers
o Cab (EA, EB) – Max 1 team of 1 worker
Vehicle exterior
o Lateral – Max 2 teams of 2 workers
o Roof – Max 2 teams of 2 workers
o Under floor – Max 2 teams of 2 workers
The majority of working stations have three up to four
teams (six up to eight workers) at a time. On Cab only
one worker is allowed.
5.4 Production schedule
The development of the production schedule for this
assembly line is a time consuming and difficult task since
it is necessary to conciliate constraints and minimize
resources, while a balance of works is required to reduce
the idle time and cost of the process. Experts make this
task manually with the know-how acquired in past
projects and constant revision of the tasks.
An Excel file containing the sheets: tasks; resources and
scheduling stores the production schedule to which the
simulation model is intended. The first sheet relates to
the list of executable tasks, the second to the list of
existing resources and the third to the list of the schedule
planning to simulate. The database must follow a fixed
format and must have the configuration shown in Fig.
11.

Fig. 11: Production scheduling data sheets example.
5.5 Simulation
The database is read by Arena, using the Visual Basic
program to communicate between softwares. The created
model is then simulated by Arena. First, possible
scheduling errors are checked. If no errors are detected,
Arena runs the simulation model.
Fig. 12: Probability distribution for the through put time
of the process studied
The simulation produces a report that stores important
information about the process. A MatLab program called
Analyzer was developed to analyze the data stored during
model creation, to identify delays due to predecessors
and shared resources, to identify the critical path, to
determine the confidence intervals and to identify the
minimum resources needed. Figures 13, 14 and 15
present some results produced by Analyzer.
Fig. 13: Statistical analysis for the throughput time of the
studied process.
Fig. 14: Confidence interval for the throughput time of
the process studied.
Utilizacao do(s) Recurso(s) ao longo do tempo
Mec 16.rdat
Mec 18.rdat
0 20 40 60 80 100 120 140 160 180 200
Tempo (em Unidades de Tempo)
Fig. 15: Comparison between the usage of two
different resources. Idle time and tasks performed by the
resources are shown.
6. CONCLUSION
This paper presents the development of a software tool to
create simulation models of flow assembly lines. One
example of a very complex model, the production line of
rolling stock vehicles, showed the powerful capabilities
of the tool, which is able to simulate a wide variety of
assembly lines. The software tool was able to reduce the
production in 45 days for a manual solution, and 8 hours
in the study of different solutions for the flow assembly
line. Also some scheduling errors in the implemented
solution at Bombardier were found. The study shown
that the major constraint of the process, i.e. the limitation
to 5% of extra time to fulfill all tasks within the bit rate
of 3 days (24 hours), is easily achieved by small
adjustments in the production schedule.
The intention of this paper was to briefly discuss the
simulation model creation process. The development
process was not shown in detail, as it can be consulted in
(Russo and Vicente, 2003). Future work will deal with
other scheduling methods based on soft computing
methods.
REFERENCES
Hssain, A., (2000). Optimisation des Flux de Production.
Methodes et Simulation, Éditions Dunod, Paris.
Russo, J., Vicente R., (2003). Análise e Simulação de
uma Linha de Montagem, Technical Report GCAR
Lisboa, Portugal.
Kelton, W., R. Sadowski, D. Sturrock (2003). Simulation
with Arena, McGraw-Hill.
Pinedo, M. (2002). Scheduling: Theory, Algorithms, and
Systems, 2 nd Edition, Prentice Hall.
Pinedo, M. and X. Chao (1999). Operations Scheduling
with Applications in Manufacturing and Services,
Irwin/McGraw Hill.

Abstract
WEB BASED SUPERVISION OF REMOTE UNITS
Rui Delgado 1 , Gustavo Santos 1 , Carlos Cardeira 1 , Rui Loureiro 1 , Otto Leichsenring 2
1 Lisbon Technical University, Instituto Superior Técnico, GCAR – DEM
1049-001 Lisboa
{rmdd,gmsa}@mega.ist.utl.pt, rui.loureiro@pt.transport.bombardier.com, carlos.cardeira@.ist.utl.pt
2 Infocontrol - Electrónica e Automatismos,
2745-740 Massamá
otto@infocontrol.pt
In this paper we present the monitoring of a remote facility, using a simple web based interface instead of the usual
monitoring and supervision system. The HMI (Human Man Interface) was developed using standard html (as well as
some Javascript instructions) providing access to the user from an internet browser without need of specific SCADA
software. Letting HMI of equipments be built as a common web page we take advantage on large expertise existing for
making web pages instead of being dependant of a specific HMI provided by a given SCADA software. A case study is
presented were we monitor the state of a remote retransmission unit and control its access remotely from a usual web
client. This work results from cooperation between university and industry. Copyright © IFAC Controlo2004
Keywords: Industry automation, Monitored control systems, Remote control, Supervision.
1. Introduction
In many applications, a facility may be located in places
difficult to access. This arises often in applications like
urban water supply, radio transmitting antennas, electric
power stations, and so on. In these applications the
facility may work remotely without human assistance for
long periods. The human presence in such systems
presents a high cost due to the difficulty on accessing
these remote locations.
Human teams usually go to these places to solve any
given problem reported by any sort of generated alarm or
for maintenance purposes, but it is important that these
visits remain unfrequent.
The usual solution is to opt for a commercial SCADA
solution, which will monitor the system and provide the
necessary alarms.
However these SCADA systems are expensive.
Moreover, some PLCs manufacturers already offer low
cost web based solutions that might provide the set of
features provided by a SCADA system. It’s up to the user
the responsibility of making the work with the languages
usually used for web browsers.
Using this approach we developed such a system
providing similar features as a commercial SCADA
system but relying on simpler techniques like
programming in html, letting the system observable from
any web browser.
To achieve this goal, this paper is organized as follows: in
section 2 we present a state of the art on existing SCADA
1
solutions; in section 3 we present a description of the
system studied and the way how communications were
handled; section 4 presents our experimental results; in
section 5 conclusions are drawn.
2. State of the art
SCADA (Supervision Control and Data Acquisition)
systems are often used to monitor remote facilities
[Bailey 2003], [Boyer 1999]. The ideal SCADA would
provide these important features:
• Run on multiple platforms (win32, unix, RTOS,
etc.)
• Have a good database support (SQL Server,
Oracle, etc.)
• Good LAN support
• Nice script languages (VBScript or JavaScript)
• Graphical Reports
• High speed historian
• Low Cost
• …
Factory Link, Rsview32, Citect, Cimplicity, iFix, Intouch,
and many others are well known commercial SCADA
systems that compete with each other trying to achieve
these goals. They usually have rich HMI (Human
Machine Interface) providing the user a complete
overview of the remote controlled system (fig 1).

Fig. 1 HMI of a typical SCADA system
In spite of all these features, commercial SCADA systems
are very expensive and some times proprietary meaning
that a SCADA systems will work better with several
brands of equipment (likely with equipment from the
same manufacturer) and will work worse or not work at
all with other brands (likely with equipment from a
concurrent manufacturer).
Web based approaches, when available, provide a nice
way to bypass these drawbacks as they are widely
available at a lower cost [Neto 2000].
3. System Description
The remote system to be monitorized is composed by a
PLC and two external connected equipments:
• Energy analyser
• Access control reader
The PLC is the Remote Terminal Unit (RTU) of the
system which communicates with a PC running a specific
Web Server (SAIA Web Connect). This part of the system
is our version of SCADA (Supervisory Control and Data
Acquisition).
The PLC used was SAIA-BURGESS PCD4.M170 which
supports the allocation of HTML files and communicates
with the SCADA, via a TCP/IP protocol. For this effect
the PLC has incorporated an Ehernet RJ45 Connector.
Energy Analyser
Remote PC
Modbus Modbus
TCP/IP
RTU
SCADA
TCP/IP
Fig 2 : System architecture.
ASCII ASCII communication
communication
Access Control
Reader
2
The RTU controls the system, communicates with the
external equipments and stores the information received
in its memory. Therefore this information can be
remotely accessed by anyone with permission, in remote
PCs. These PCs communicate via TCP/IP with the Web
Server that runs in the SCADA.
The tasks that control the system were programmed in
Graftec language (a specific SAIA language similar to
Grafcet) and downloaded to the PLC using the SAIA PG5
application.
The energy analyser used was Electrex Kilo (3 phase
energy analyser/controller). It was connected to a serial
communication port of the PLC over an RS485 link,
using Modbus protocol. Modbus is an open, serial
communications protocol based on the master/slave
architecture.
The Access Control Reader used was PRX-4. The
communication protocol for this device is pure ASCII
based, and was implemented over an RS232 serial link to
the PLC.
The group formed by the RTU and its external connected
equipments are viewed remotely as stations.
3.1. Communication RTU-SCADA
The communication between the PLC and the PC running
the Web Server can be made using TCP/IP, S-BUS or
PGU. The last two modes use a RS232 connection. The
communication and respective configuration is made with
the Web Server provided by SAIA-BURGESS (SAIA
Web Connect) which is installed in the PC [SAIA 2003].
SAIA-Burgess Web Server functions are splitted: The
PLC has the responsibility to do the file administration
while the PC running the Web Server handles the requests
from TCP/IP communications used to call control and
monitoring functions. It’s then possible to communicate
between the PC and PLC using a simple, efficient
protocol that uses fewer resources than TCP/IP. Reduced
to the essential transfer function, this protocol does not
affect the real-time behaviour of the PLC.
Standard browsers, like Microsoft Internet Explorer or
Netscape Communicator, make file requests to the Web
Server using the TCP/IP protocol. To enable
communication with the Web Server in the PLC, the Web
Connect software must be installed on a PC, which works
as the communication part of the Web Server. Web
Connect receives those requests from the browser using
the TCP/IP protocol and forwards them with an efficient
protocol from the PC to the PLC. This is made using one
of the possible communication modes previously
configured. PLC answers are converted back into TCP/IP
and sent to the browser.

Some advantages of this Web Server are:
• Simple and low-cost creation of control and
monitoring interfaces with familiar HTML editors,
such as Frontpage or Dreamweaver.
• Control and Monitoring of the system accessing the
interface with commonly used web browsers, like
Microsoft Internet Explorer or Netscape
Communicator.
The Web Server allows the configuration of multiple
stations using different communication modes.
Fig 3 : SAIA Web Connect General Setup
The configuration is made using a setup page pre-built in
the Web Server accessed with a common web browser at
the location http://pc-ip-address/setup, exemplified in Fig
3. In our case the station was connected via TCP/IP.
After the station configuration the Web Interface can be
accessed at the location http://pc-ip-address/stationname/.
Fig 4: Web Server individual Elements
2.2.1. HTML Server
The HTML Server is the core of the Web Server. Its
function is sending HTML pages requested by the Web
Browser (as well as images) across the S-BUS Driver to
the PC. HTML pages or images are stored in the user files
3
memory of the PLC, which were previously
downloaded to it, along with the remaining program.
The HTML server also checks HTML pages for possible
existing process data point identification key (PDP key).
When the HTML Server finds a PDP key in a HTML
page, sends it to the Data Server.
PDP keys are embedded in the HTML code, being used
for addressing PLC data. In a brief description of the tag,
it starts with the PDP identification, then the characters
“,,”. After these, come the media area and the address of
the media. Depending on the media type it is possible to
have a range of values, so numbers of elements can be
specified, separated with the address by “/”. At the end,
separated with a comma, the representation format is
specified.
Below are some examples of these keys application:
• %%PDP,,I16,B% addressing one input “I16” and
format is binary.
• %%PDP,,R300,F% addressing the register 300,
format is in floating point.
• %%PDP,,DB10.20,d% addressing Data Block 10,
element 20, format is decimal.
2.2.2. Data Server
The Data Server processes PDP keys received from the
HTML Server and transfers them in the requested PLC
data directly from the PLC’s memory to the HTML
Server.
The Data Server can access registers, flags, data blocks,
inputs, outputs, timers, counters, texts and PLC status.
2.2.3.User Files
One of the Web Server big advantages is the creation of a
monitoring and control interface using any tool that
generates HTML. Any tables, graphics, pictures, etc. that
can be displayed by the web browser may be inserted.
All HTML pages, images or files added by the user are
stored in the PLC as data blocks of the user program. The
user is able to store any file in any preferred format and
with whatever suffix (*.htm, *.html, *.bmp, *.gif, *.txt,
*.zip or any other) in the PLC, as long as the file does not
exceed 100 KByte in size.
The HTML Server only checks files with suffix *.html or
*.htm for PDP keys.
2.2.4. Local Files
If the files are too large, like big images, or the user
simply doesn’t want to store them in the PLC memory, it
is possible to store them in the Web Connect directory in
the PC hard drive (local files).
When the file is requested and it doesn’t exist in the PLC
memory, the Web Connect will check the local directory

and load it. This operation is transparent to the user that is
using the interface.
2.2.5. Web Builder
The programming tool used to program the PLC’s is PG5.
The control and monitoring files are then stored in the
PLC’s user files memory.
All HTML pages, images, etc, are stored in the user
program of PG5, but these files must first be converted
into source files to be integrated in the project. The
conversion tool used for this purpose is Web Builder.
This tool is used to add and remove HTML files and
images from the project and then generate a source file.
That file is then compiled with the remaining control files
and downloaded into the PLC.
3.2. External Equipments
3.2.1. Energy Analyser
The energy analyser is used to measure several local
variables to the station that influence the performance of
the system.
The RTU communicates with the energy analyser (Kilo)
via a Modbus protocol in which the first is the master and
the second is the slave. Only the master can begin the
dialogue with the slave. As referred above the
communication was made with a RTU serial port in a
RS485 link.
This equipment is used to measure AC Voltage,
Temperatures, Current, Active and Reactive Power and
Energy, Power Factor and Maximum Demand.
The RTU memory is used to store the measured values as
real-time variables, in registers, but also used as a buffer
to make historical registries over an integration period.
This enables the SCADA to build profiles and to follow
the variables evolution, constructing graphics (Fig 5),
tables, etc.
We can also define the allowed values for the variables.
When the measured values exceed these limits the RTU
produces time stamped alarms that are communicated to
the SCADA and to the responsible technicians.
4
Fig 5 : Portion of a HTML web page with a graphic based
on the values measured with the energy analyser
3.2.2. Access Control Reader
The access control reader is used to give access to stations
for local maintenance. In this way, when the access right
is granted the door will be opened by the RTU which will
control the access control reader.
The communication between and PRX-4 and the RTU is
pure ASCII based and was made using an RS232 serial
link.
The access control reader will only receive the codes from
the magnetic cards and the validation is made by the
RTU. So when a card is passed in the PRX-4 the
respective code will be copied to the RTU temporary
memory which will compare it with a list of valid codes
that have the access rights to the station. If the read code
appears in the list a RTU output will open the door and
this access will be recorded in the RTU memory.
As mentioned above there are two kinds of information to
be recorded in the RTU memory, so two buffers can be
distinguished:
• access control codes, which stores the valid
access codes to the station
• access control, which registers the physical
access to the station. Each access will be
represented by its code, date and time of access.
Each code, and consequently the associated access right,
will have a validity period (end date) and/or number of
entries. So every time a card is validated the number of
allowed entries has to be decremented. When this number
reaches zero the code is deleted from the RTU memory.
In the same way at the end of each day the RTU will
delete the codes for which the end date is no longer valid.
If a code has both a validity period and a number of
entries allowed the code will be deleted when the first of
the two expires.

4. Experimental Results
As a practical example to illustrate the performance of the
system and its architecture it’s presented bellow the
supervision of the access rights, which integrates some
elements referred above.
The first step was to introduce codes in the system, so
they can be read and validated when a respective
magnetic card is locally passed in the PRX-4. These codes
also need to be supervised: remotely visualization and
deletion.
In this way this section was divided in three sub-sections
according to the tasks referred.
All the programming was made in Graftec language (Fig
6) in the RTU side and in Javascript and HTML (Fig 7,8)
for the Web pages.
The Graftec routines programmed run in parallel in the
RTU.
Fig 6: Graftec example main routine for access codes
validation
4.1. Access Codes Insertion
To insert a code in the system an authorized person just
needs to know the IP of the station, configured with the
Web Connect application, and access it with a browser at
a remote PC.
5
Fig 7 : Portion of a HTML web page with the form that
allows the insertion of an access code in the system
In the first place HTML pages were built in an editor.
These pages (fig 7) give the possibility to insert a code in
the RTU access control codes buffer and to configure its
validity. After the insertion of these parameters a web
page is loaded with the embedded PDP keys in it, as
shown in Fig 8.
Fig 8: HTML example, which calls a Javascript function,
and has PDP keys embedded
This HTML form receives the data from the previous
page using cookies and puts it in its “hidden” fields.
When the “Confirm” button of the form is clicked each
character of the code is translated to its correspondent
ASCII value (with the help of a Javascript function), and
loaded to consecutive registers, together with its validity
parameters.
Then this data needs to be copied to the access control
codes buffer, which is a RTU data-block.
To execute this, a routine was programmed which is
constantly running in the RTU and, when detects the
insertion of a code, transfers it from the registries to the
data-block correct position and increments the number of
cards of the system.
Instead of loading the data from the page to registers, they
could have been loaded directly to the data-blocks.
However this would difficult the task, because we would
have to first get the number of codes in the system to
insert the code the correct position, and the PDP keys
parameters would have to be dynamic.

With the chosen option the web pages and the RTU are
totally separated.
Each code was saved using one data-block position for
each character of it because of the way the codes are read
from the card reader, described bellow.
4.2. Access Codes Validation
For this task a Graftec (Fig 6) constantly runs in the PLC
waiting the arrival of codes to the access control reader.
In the fist place the establishment of the communication
with the PRX-4 card reader needed to be done. For this,
specific SASI SAIA PLC instructions were used. Then
the PRX-4 was put in the “Card read mode” for which it
sends automatically the code number, in ASCII, of the
card being read through the serial channel.
This code, is stored in a serial receive buffer and several
diagnostic flags are actualized.
Because of limitations of the programming language, the
reading of the receive buffer can only be done character
by character.
When a card is passed in the card reader the content of the
receive buffer is transferred to consecutive registries.
Next the read code is searched in the access control codes
buffer and, if it’s valid, an output is set that simulates the
opening of the door.
In this case the recording of this access in the access
control buffer needs to be done, saving it with the
respective date and time. This buffer is also a data-block.
If the code has validity by number of accesses the actual
number of entries is incremented and if reaches the total
number allowed a flag that activates the routine that
automatically deletes the code from the system is set.
4.3. Codes Supervision
To supervise the valid codes and the time stamped
accesses recorded in the RTU respective buffers PDP
keys are simply embedded in the HTML code and in any
browser this information can be visualised.
To delete the codes from the system a Graftec routine is
constantly running in the RTU waiting for the set of a flag
which activates it.
This can happen in three situations:
• When an authorized user explicitly gives the order
for it in a Web page. In this case each code number is
copied to temporary RTU registries to know what
code to delete.
• When the actual number of accesses for a card
reaches the total allowed.
• When the actual date equals the end date allowed.
6
In each situation the coorresponding code is searched and
deleted from the access control codes buffer and the
number of codes in the system is decremented.
For the third case another routine was programmed, that
at the end of each day searches for invalid end dates and
in those cases simply sets the flag referred.
5. Conclusion and further work
The web based supervision system presented monitors the
state of a remote facility reducing the number of human
local assistances.
The system is able to:
• control the access to the station
• allow or deny the access to the facility in
function of the codes validity
• update the codes validity remotely
• maintain an historic file with the hour and date
of the accesses
• be accessed remotely by a normal web client
Moreover the system will be able to scan a given number
of data important to the system, like temperature, supply
voltages, active and reactive power, and others that are
important to predict failures and have the power to
reinitialize the system.
With this work we avoid the need of an expensive
SCADA system, using a much simpler approach, meeting
the requirements made by the industry.
6. Acknowledgements
This work is being supported by INFOCONTROL, which
provided us the experimental setup to develop the
monitored system and the base document of the system to
be conceived, written by Fernando Pimenta.
This work was developed in a research laboratory
supported by POCTI, FCT, Ministério da Ciência e do
Ensino Superior.
References
[Bailey 2003] D. Bailey, E. Wright, SCADA for Industry,
Newnes, 2003.
[Boyer 1999], S. Boyer, SCADA: Supervisory Control
and Data Acquisition, ISA - The Instrumentation,
Systems, and Automation Society, 1999
[Neto 2000] R. Neto, João Alves, Jorge Alves, A.
Carvalho, I. Fonseca, N. Miguel, E. Emílio, H. Fachada,
"Remote Control of Industrial Processes", Controlo’2000:
4th Portuguese Conference on Automatic Control,
Guimarães, October 4-6, 2000
[Saia 2003] Saia - Burguess, "Manual Web-Server
Classic", document n. 26/790, Edition E2, 18.05.2003.

Abstract
WEB BASED SUPERVISION OF REMOTE UNITS
Rui Delgado 1 , Gustavo Santos 1 , Carlos Cardeira 1 , Rui Loureiro 1 , Otto Leichsenring 2
1 Lisbon Technical University, Instituto Superior Técnico, GCAR – DEM
1049-001 Lisboa
{rmdd,gmsa}@mega.ist.utl.pt, rui.loureiro@pt.transport.bombardier.com, carlos.cardeira@.ist.utl.pt
2 Infocontrol - Electrónica e Automatismos,
2745-740 Massamá
otto@infocontrol.pt
In this paper we present the monitoring of a remote facility, using a simple web based interface instead of the usual
monitoring and supervision system. The HMI (Human Man Interface) was developed using standard html (as well as
some Javascript instructions) providing access to the user from an internet browser without need of specific SCADA
software. Letting HMI of equipments be built as a common web page we take advantage on large expertise existing for
making web pages instead of being dependant of a specific HMI provided by a given SCADA software. A case study is
presented were we monitor the state of a remote retransmission unit and control its access remotely from a usual web
client. This work results from cooperation between university and industry. Copyright © IFAC Controlo2004
Keywords: Industry automation, Monitored control systems, Remote control, Supervision.
1. Introduction
In many applications, a facility may be located in places
difficult to access. This arises often in applications like
urban water supply, radio transmitting antennas, electric
power stations, and so on. In these applications the
facility may work remotely without human assistance for
long periods. The human presence in such systems
presents a high cost due to the difficulty on accessing
these remote locations.
Human teams usually go to these places to solve any
given problem reported by any sort of generated alarm or
for maintenance purposes, but it is important that these
visits remain unfrequent.
The usual solution is to opt for a commercial SCADA
solution, which will monitor the system and provide the
necessary alarms.
However these SCADA systems are expensive.
Moreover, some PLCs manufacturers already offer low
cost web based solutions that might provide the set of
features provided by a SCADA system. It’s up to the user
the responsibility of making the work with the languages
usually used for web browsers.
Using this approach we developed such a system
providing similar features as a commercial SCADA
system but relying on simpler techniques like
programming in html, letting the system observable from
any web browser.
To achieve this goal, this paper is organized as follows: in
section 2 we present a state of the art on existing SCADA
1
solutions; in section 3 we present a description of the
system studied and the way how communications were
handled; section 4 presents our experimental results; in
section 5 conclusions are drawn.
2. State of the art
SCADA (Supervision Control and Data Acquisition)
systems are often used to monitor remote facilities
[Bailey 2003], [Boyer 1999]. The ideal SCADA would
provide these important features:
• Run on multiple platforms (win32, unix, RTOS,
etc.)
• Have a good database support (SQL Server,
Oracle, etc.)
• Good LAN support
• Nice script languages (VBScript or JavaScript)
• Graphical Reports
• High speed historian
• Low Cost
• …
Factory Link, Rsview32, Citect, Cimplicity, iFix, Intouch,
and many others are well known commercial SCADA
systems that compete with each other trying to achieve
these goals. They usually have rich HMI (Human
Machine Interface) providing the user a complete
overview of the remote controlled system (fig 1).

Fig. 1 HMI of a typical SCADA system
In spite of all these features, commercial SCADA systems
are very expensive and some times proprietary meaning
that a SCADA systems will work better with several
brands of equipment (likely with equipment from the
same manufacturer) and will work worse or not work at
all with other brands (likely with equipment from a
concurrent manufacturer).
Web based approaches, when available, provide a nice
way to bypass these drawbacks as they are widely
available at a lower cost [Neto 2000].
3. System Description
The remote system to be monitorized is composed by a
PLC and two external connected equipments:
• Energy analyser
• Access control reader
The PLC is the Remote Terminal Unit (RTU) of the
system which communicates with a PC running a specific
Web Server (SAIA Web Connect). This part of the system
is our version of SCADA (Supervisory Control and Data
Acquisition).
The PLC used was SAIA-BURGESS PCD4.M170 which
supports the allocation of HTML files and communicates
with the SCADA, via a TCP/IP protocol. For this effect
the PLC has incorporated an Ehernet RJ45 Connector.
Energy Analyser
Remote PC
Modbus Modbus
TCP/IP
RTU
SCADA
TCP/IP
Fig 2 : System architecture.
ASCII ASCII communication
communication
Access Control
Reader
2
The RTU controls the system, communicates with the
external equipments and stores the information received
in its memory. Therefore this information can be
remotely accessed by anyone with permission, in remote
PCs. These PCs communicate via TCP/IP with the Web
Server that runs in the SCADA.
The tasks that control the system were programmed in
Graftec language (a specific SAIA language similar to
Grafcet) and downloaded to the PLC using the SAIA PG5
application.
The energy analyser used was Electrex Kilo (3 phase
energy analyser/controller). It was connected to a serial
communication port of the PLC over an RS485 link,
using Modbus protocol. Modbus is an open, serial
communications protocol based on the master/slave
architecture.
The Access Control Reader used was PRX-4. The
communication protocol for this device is pure ASCII
based, and was implemented over an RS232 serial link to
the PLC.
The group formed by the RTU and its external connected
equipments are viewed remotely as stations.
3.1. Communication RTU-SCADA
The communication between the PLC and the PC running
the Web Server can be made using TCP/IP, S-BUS or
PGU. The last two modes use a RS232 connection. The
communication and respective configuration is made with
the Web Server provided by SAIA-BURGESS (SAIA
Web Connect) which is installed in the PC [SAIA 2003].
SAIA-Burgess Web Server functions are splitted: The
PLC has the responsibility to do the file administration
while the PC running the Web Server handles the requests
from TCP/IP communications used to call control and
monitoring functions. It’s then possible to communicate
between the PC and PLC using a simple, efficient
protocol that uses fewer resources than TCP/IP. Reduced
to the essential transfer function, this protocol does not
affect the real-time behaviour of the PLC.
Standard browsers, like Microsoft Internet Explorer or
Netscape Communicator, make file requests to the Web
Server using the TCP/IP protocol. To enable
communication with the Web Server in the PLC, the Web
Connect software must be installed on a PC, which works
as the communication part of the Web Server. Web
Connect receives those requests from the browser using
the TCP/IP protocol and forwards them with an efficient
protocol from the PC to the PLC. This is made using one
of the possible communication modes previously
configured. PLC answers are converted back into TCP/IP
and sent to the browser.

Some advantages of this Web Server are:
• Simple and low-cost creation of control and
monitoring interfaces with familiar HTML editors,
such as Frontpage or Dreamweaver.
• Control and Monitoring of the system accessing the
interface with commonly used web browsers, like
Microsoft Internet Explorer or Netscape
Communicator.
The Web Server allows the configuration of multiple
stations using different communication modes.
Fig 3 : SAIA Web Connect General Setup
The configuration is made using a setup page pre-built in
the Web Server accessed with a common web browser at
the location http://pc-ip-address/setup, exemplified in Fig
3. In our case the station was connected via TCP/IP.
After the station configuration the Web Interface can be
accessed at the location http://pc-ip-address/stationname/.
Fig 4: Web Server individual Elements
2.2.1. HTML Server
The HTML Server is the core of the Web Server. Its
function is sending HTML pages requested by the Web
Browser (as well as images) across the S-BUS Driver to
the PC. HTML pages or images are stored in the user files
3
memory of the PLC, which were previously
downloaded to it, along with the remaining program.
The HTML server also checks HTML pages for possible
existing process data point identification key (PDP key).
When the HTML Server finds a PDP key in a HTML
page, sends it to the Data Server.
PDP keys are embedded in the HTML code, being used
for addressing PLC data. In a brief description of the tag,
it starts with the PDP identification, then the characters
“,,”. After these, come the media area and the address of
the media. Depending on the media type it is possible to
have a range of values, so numbers of elements can be
specified, separated with the address by “/”. At the end,
separated with a comma, the representation format is
specified.
Below are some examples of these keys application:
• %%PDP,,I16,B% addressing one input “I16” and
format is binary.
• %%PDP,,R300,F% addressing the register 300,
format is in floating point.
• %%PDP,,DB10.20,d% addressing Data Block 10,
element 20, format is decimal.
2.2.2. Data Server
The Data Server processes PDP keys received from the
HTML Server and transfers them in the requested PLC
data directly from the PLC’s memory to the HTML
Server.
The Data Server can access registers, flags, data blocks,
inputs, outputs, timers, counters, texts and PLC status.
2.2.3.User Files
One of the Web Server big advantages is the creation of a
monitoring and control interface using any tool that
generates HTML. Any tables, graphics, pictures, etc. that
can be displayed by the web browser may be inserted.
All HTML pages, images or files added by the user are
stored in the PLC as data blocks of the user program. The
user is able to store any file in any preferred format and
with whatever suffix (*.htm, *.html, *.bmp, *.gif, *.txt,
*.zip or any other) in the PLC, as long as the file does not
exceed 100 KByte in size.
The HTML Server only checks files with suffix *.html or
*.htm for PDP keys.
2.2.4. Local Files
If the files are too large, like big images, or the user
simply doesn’t want to store them in the PLC memory, it
is possible to store them in the Web Connect directory in
the PC hard drive (local files).
When the file is requested and it doesn’t exist in the PLC
memory, the Web Connect will check the local directory

and load it. This operation is transparent to the user that is
using the interface.
2.2.5. Web Builder
The programming tool used to program the PLC’s is PG5.
The control and monitoring files are then stored in the
PLC’s user files memory.
All HTML pages, images, etc, are stored in the user
program of PG5, but these files must first be converted
into source files to be integrated in the project. The
conversion tool used for this purpose is Web Builder.
This tool is used to add and remove HTML files and
images from the project and then generate a source file.
That file is then compiled with the remaining control files
and downloaded into the PLC.
3.2. External Equipments
3.2.1. Energy Analyser
The energy analyser is used to measure several local
variables to the station that influence the performance of
the system.
The RTU communicates with the energy analyser (Kilo)
via a Modbus protocol in which the first is the master and
the second is the slave. Only the master can begin the
dialogue with the slave. As referred above the
communication was made with a RTU serial port in a
RS485 link.
This equipment is used to measure AC Voltage,
Temperatures, Current, Active and Reactive Power and
Energy, Power Factor and Maximum Demand.
The RTU memory is used to store the measured values as
real-time variables, in registers, but also used as a buffer
to make historical registries over an integration period.
This enables the SCADA to build profiles and to follow
the variables evolution, constructing graphics (Fig 5),
tables, etc.
We can also define the allowed values for the variables.
When the measured values exceed these limits the RTU
produces time stamped alarms that are communicated to
the SCADA and to the responsible technicians.
4
Fig 5 : Portion of a HTML web page with a graphic based
on the values measured with the energy analyser
3.2.2. Access Control Reader
The access control reader is used to give access to stations
for local maintenance. In this way, when the access right
is granted the door will be opened by the RTU which will
control the access control reader.
The communication between and PRX-4 and the RTU is
pure ASCII based and was made using an RS232 serial
link.
The access control reader will only receive the codes from
the magnetic cards and the validation is made by the
RTU. So when a card is passed in the PRX-4 the
respective code will be copied to the RTU temporary
memory which will compare it with a list of valid codes
that have the access rights to the station. If the read code
appears in the list a RTU output will open the door and
this access will be recorded in the RTU memory.
As mentioned above there are two kinds of information to
be recorded in the RTU memory, so two buffers can be
distinguished:
• access control codes, which stores the valid
access codes to the station
• access control, which registers the physical
access to the station. Each access will be
represented by its code, date and time of access.
Each code, and consequently the associated access right,
will have a validity period (end date) and/or number of
entries. So every time a card is validated the number of
allowed entries has to be decremented. When this number
reaches zero the code is deleted from the RTU memory.
In the same way at the end of each day the RTU will
delete the codes for which the end date is no longer valid.
If a code has both a validity period and a number of
entries allowed the code will be deleted when the first of
the two expires.

4. Experimental Results
As a practical example to illustrate the performance of the
system and its architecture it’s presented bellow the
supervision of the access rights, which integrates some
elements referred above.
The first step was to introduce codes in the system, so
they can be read and validated when a respective
magnetic card is locally passed in the PRX-4. These codes
also need to be supervised: remotely visualization and
deletion.
In this way this section was divided in three sub-sections
according to the tasks referred.
All the programming was made in Graftec language (Fig
6) in the RTU side and in Javascript and HTML (Fig 7,8)
for the Web pages.
The Graftec routines programmed run in parallel in the
RTU.
Fig 6: Graftec example main routine for access codes
validation
4.1. Access Codes Insertion
To insert a code in the system an authorized person just
needs to know the IP of the station, configured with the
Web Connect application, and access it with a browser at
a remote PC.
5
Fig 7 : Portion of a HTML web page with the form that
allows the insertion of an access code in the system
In the first place HTML pages were built in an editor.
These pages (fig 7) give the possibility to insert a code in
the RTU access control codes buffer and to configure its
validity. After the insertion of these parameters a web
page is loaded with the embedded PDP keys in it, as
shown in Fig 8.
Fig 8: HTML example, which calls a Javascript function,
and has PDP keys embedded
This HTML form receives the data from the previous
page using cookies and puts it in its “hidden” fields.
When the “Confirm” button of the form is clicked each
character of the code is translated to its correspondent
ASCII value (with the help of a Javascript function), and
loaded to consecutive registers, together with its validity
parameters.
Then this data needs to be copied to the access control
codes buffer, which is a RTU data-block.
To execute this, a routine was programmed which is
constantly running in the RTU and, when detects the
insertion of a code, transfers it from the registries to the
data-block correct position and increments the number of
cards of the system.
Instead of loading the data from the page to registers, they
could have been loaded directly to the data-blocks.
However this would difficult the task, because we would
have to first get the number of codes in the system to
insert the code the correct position, and the PDP keys
parameters would have to be dynamic.

With the chosen option the web pages and the RTU are
totally separated.
Each code was saved using one data-block position for
each character of it because of the way the codes are read
from the card reader, described bellow.
4.2. Access Codes Validation
For this task a Graftec (Fig 6) constantly runs in the PLC
waiting the arrival of codes to the access control reader.
In the fist place the establishment of the communication
with the PRX-4 card reader needed to be done. For this,
specific SASI SAIA PLC instructions were used. Then
the PRX-4 was put in the “Card read mode” for which it
sends automatically the code number, in ASCII, of the
card being read through the serial channel.
This code, is stored in a serial receive buffer and several
diagnostic flags are actualized.
Because of limitations of the programming language, the
reading of the receive buffer can only be done character
by character.
When a card is passed in the card reader the content of the
receive buffer is transferred to consecutive registries.
Next the read code is searched in the access control codes
buffer and, if it’s valid, an output is set that simulates the
opening of the door.
In this case the recording of this access in the access
control buffer needs to be done, saving it with the
respective date and time. This buffer is also a data-block.
If the code has validity by number of accesses the actual
number of entries is incremented and if reaches the total
number allowed a flag that activates the routine that
automatically deletes the code from the system is set.
4.3. Codes Supervision
To supervise the valid codes and the time stamped
accesses recorded in the RTU respective buffers PDP
keys are simply embedded in the HTML code and in any
browser this information can be visualised.
To delete the codes from the system a Graftec routine is
constantly running in the RTU waiting for the set of a flag
which activates it.
This can happen in three situations:
• When an authorized user explicitly gives the order
for it in a Web page. In this case each code number is
copied to temporary RTU registries to know what
code to delete.
• When the actual number of accesses for a card
reaches the total allowed.
• When the actual date equals the end date allowed.
6
In each situation the coorresponding code is searched and
deleted from the access control codes buffer and the
number of codes in the system is decremented.
For the third case another routine was programmed, that
at the end of each day searches for invalid end dates and
in those cases simply sets the flag referred.
5. Conclusion and further work
The web based supervision system presented monitors the
state of a remote facility reducing the number of human
local assistances.
The system is able to:
• control the access to the station
• allow or deny the access to the facility in
function of the codes validity
• update the codes validity remotely
• maintain an historic file with the hour and date
of the accesses
• be accessed remotely by a normal web client
Moreover the system will be able to scan a given number
of data important to the system, like temperature, supply
voltages, active and reactive power, and others that are
important to predict failures and have the power to
reinitialize the system.
With this work we avoid the need of an expensive
SCADA system, using a much simpler approach, meeting
the requirements made by the industry.
6. Acknowledgements
This work is being supported by INFOCONTROL, which
provided us the experimental setup to develop the
monitored system and the base document of the system to
be conceived, written by Fernando Pimenta.
This work was developed in a research laboratory
supported by POCTI, FCT, Ministério da Ciência e do
Ensino Superior.
References
[Bailey 2003] D. Bailey, E. Wright, SCADA for Industry,
Newnes, 2003.
[Boyer 1999], S. Boyer, SCADA: Supervisory Control
and Data Acquisition, ISA - The Instrumentation,
Systems, and Automation Society, 1999
[Neto 2000] R. Neto, João Alves, Jorge Alves, A.
Carvalho, I. Fonseca, N. Miguel, E. Emílio, H. Fachada,
"Remote Control of Industrial Processes", Controlo’2000:
4th Portuguese Conference on Automatic Control,
Guimarães, October 4-6, 2000
[Saia 2003] Saia - Burguess, "Manual Web-Server
Classic", document n. 26/790, Edition E2, 18.05.2003.