The use of Interaction Laws on Air Traffic

The use of Interaction Laws on Air Traffic Control for Specifying Dependable Interactions Rodrigo Paes rbp@les. inf. puc-rio. br

Outline • Descrição do Trabalho • Objetivos • Resultados Esperados • Bibliografia Preliminar © LES/PUC-Rio

Scope • In many today’s distributed system, interaction can be very complex; • … and more: – Complex behavioral rules – Ex. : Notion of commitment, time-sensitive restrictions, contextbased validations © LES/PUC-Rio

Current scenario • Usually, those rules are hard-coded in the distributed entities themselves (lets call them agents) Hard-coded interaction-related rules © LES/PUC-Rio

Some issues • How can we guarantee the behavioral rules are been followed? – In open systems, agents are developed by different teams, and they can have conflicting interests (one want to buy cheap, but the seller doesn’t) • How can those rules be documented in a way that designers can implement their agents in conformance with the rules? • What if the rules change? • How a bad “rule-follower” can be punished? © LES/PUC-Rio

Architecture © LES/PUC-Rio

XMLaw – The Law Meta-Model • A vocabulary to talk about interaction laws • One can think of laws as a DSL for programming the mediator © LES/PUC-Rio

Exemplo XMLaw 01: update. Product. Information{ 02: msg 1{senior, db. Agent, $product. Info 1} 03: msg 2{(senior|manager), db. Agent, $product. Info 2} 04: s 1{initial} 05: s 3{success} 06: s 6{failure} 07: s 8{failure} 08: t 1{s 1 ->s 2, msg 1} 09: t 2{s 2 ->s 3, msg 2, [ check. Content]} 10: t 3{s 1 ->s 4, msg 2} 11: t 4{s 4 ->s 3, msg 1, [ check. Content]} 12: t 5{s 2 ->s 5, timeout 1} 13: t 6{s 5 ->s 3, msg 2, [ check. Content]} 14: t 7{s 5 ->s 6, timeout 1} 15: t 8{s 4 ->s 7, timeout 2} 16: t 9{s 7 ->s 3, msg 1, [ check. Content]} 17: t 10{s 7 ->s 8, timeout 2} // Clocks 18: timeout 1{120000, periodic, (t 1), (t 2, t 6)} 19: timeout 2{120000, periodic, (t 3), (t 4, t 9)} // Constraints 20: check. Content{br. pucrio. Check. Content} // Actions 21: keep. Content{(t 1, t 3), br. pucrio. Keep. Content} // Actions for fault handling 22: handle. Timeout{(t 7, t 10), br. pucrio. Timeout. Handler } 23: handle. Different. Content{(check. Content ), br. pucrio. Dif. Content. Handler } 24: warn. Manager. Broadcast{(t 5, t 8), br. pucrio. Retry} 25: } © LES/PUC-Rio

Objetivos • Aplicar as leis para especificar preocupações de dependability • Usar o middleware para “agir”, aumentando a dependability do sistema • Contexto: Controle de Tráfego Aéreo • Resultado esperado – Mostrar que o modelo de leis é flexível para especificar “questões” de dependability © LES/PUC-Rio

Estudo de Caso • Planejamento – Definir a natureza de leis – Especificar usando o XMLaw (versão com nova sintaxe) – Implementar novo Interpretador para o XMLaw – Implementar usando o M-Law – Escrever Monografia © LES/PUC-Rio

Bibliografia Preliminar • Sales, C. R. , Sala de Regulamento de Tráfego Aéreo; http: //www. airandinas. com/ - acessado em 18/01/2007 • Ljungberg, M. and A. Lucas, The OASIS Air Traffic Management System, in Second Pacific Rim International Conference on Artificial Intelligence. 1992: Seoul, Korea. • Ndovie, B. , Simulation of a conflict management system for air traffic control, in Second International Working Conference on CKBS. 1994: DAKE Centre, University of Keele. • Felici, M. , Capturing Emerging Complex Interactions - Safety Analysis in ATM, in Workshop on Complexity in Design and Engineering. 2005: Edinburgh, Scotlad. © LES/PUC-Rio

Obrigado! Rodrigo Paes rbp@les. inf. puc-rio. br