Software/Systems Development at the Australian

advertisement
Geoscience Australia
Software Development at
the Australian Tsunami
Warning System
Background





2004 Boxing Day Tsunami.
Over 230,000 people die in Indian Ocean coastal areas.
In 2005, Australian Government decides to fund a
national Tsunami alert system.
The Joint Australian Tsunami Warning Centre
(JATWC) was born.
Became operational and launched in 2008.
© Commonwealth of Australia (Geoscience Australia) 2011
Overview




The JATWC is a joint mission between Geoscience
Australia (GA)and the Australian Bureau of
Meteorology (BOM).
GA’s mission is to detect Tsunami earthquakes with the
potential to impact Australia, and notify BOM and
other government agencies.
BOM’s mission is to perform Tsunami modelling,
assess impact on Australia (where, how bad), and issue
public and media alerts.
Operates 24/7 year round.
© Commonwealth of Australia (Geoscience Australia) 2011
GA Component - ATWS




The Australian Tsunami Warning System (ATWS) is the
GA component of the JATWC.
Was decided early on to use Antelope as the basic data
flow and processing framework.
Consists of an extensive software stack built on top of
Antelope providing all the capabilities needed to review
and communicate EQ alerts.
Is operated by duty seismologists who work in 12 hour
shifts, with one person on duty at a time.
© Commonwealth of Australia (Geoscience Australia) 2011
ATWS A Closer Look

System is spread across several servers:







DC – seismic data collection (orb2orb, seedlink etc.)
ALERT – event processing (orbassoc, evproc etc.)
IS – post-event review and analysis (dbloc2)
PUB – data dissemination (orb, seedlink, autodrm)
Most of our software runs on ALERT, including our
key Decision Support Tool (DSS) .
The majority of ATWS software is written in Perl, with
some components written in C.
Run on Solaris/SPARC servers.
© Commonwealth of Australia (Geoscience Australia) 2011
ATWS DSS “orbevents”





Main tool used to review automatic events and send out
alerts.
Uses a manual Mwp process to provide magnitude
estimates for EQs with mag > 6.
Is written in C using the Gtk+ graphics toolkit.
Sends both alerts (red) and notifications (green).
Used in conjunction with dbloc2, with the latter used
for more in-depth review, especially for small local
events.
© Commonwealth of Australia (Geoscience Australia) 2011
ATWS DSS “orbevents”
© Commonwealth of Australia (Geoscience Australia) 2011
Manual Mwp Tool
© Commonwealth of Australia (Geoscience Australia) 2011
Other Software

Heads up displays


Integration with Earthquake Catalogue


Web pages that show station latency and epicentres
on a map.
Automatically load automatic and manual solutions
into corporate Oracle database.
Automated alarm system

Watches automatic events and send out emails, rings
phones when triggered.
© Commonwealth of Australia (Geoscience Australia) 2011
Heads up display (EQs)
© Commonwealth of Australia (Geoscience Australia) 2011
Heads up display (latency)
© Commonwealth of Australia (Geoscience Australia) 2011
Process of Improvement


Kent and I identified several areas of improvement that
were critical in supporting a mission-critical system.
These include





Effective use of version control and SW packaging.
Deployment practices and configuration management.
Comprehensive system monitoring.
Planned release process (Agile methodology).
Have largely been implemented, resulting in much
better management of the system.
© Commonwealth of Australia (Geoscience Australia) 2011
Version Control




Some basic questions:
 What is currently running in production?
 What was the last change made?
Important to be able to answer these if serious about
running an operational system.
Version control is an enabler that allows them to be
answered.
Previously code was released, then sometimes checked
into VC as an afterthought.
© Commonwealth of Australia (Geoscience Australia) 2011
Version Control (cont)




Now all code must be checked into VC before it can be
released into production.
Also can see what changed by comparing two previous
release tags (useful for identifying cause of issues).
Supports release management – lets review what
changed before we release to production.
Source code only – maintain knowledge of how to
build, in case one day we need to!
© Commonwealth of Australia (Geoscience Australia) 2011
Version Control (cont)
© Commonwealth of Australia (Geoscience Australia) 2011
Deployment and Configuration





Consolidated configuration module common to all
servers release as a Solaris package.
We use a configuration management tool (Cfengine3)
that “knows” how to copy the right files based on the
current server to the right spot.
Only files that have been changed are updated.
Cfengine can also restart processes if needed.
Also provides documentation of system configuration.
Re-deploying a server is easy.
© Commonwealth of Australia (Geoscience Australia) 2011
System Monitoring






How do you know everything is running OK right now?
Comprehensive System Monitoring is key.
We use Nagios3 to do deep application level monitoring
across all processes on all servers.
Why Nagios? Standard, proven, open-source.
We monitor the status of all application processes,
including processes under rtexec.
How? Generate the Nagios configuration from rtexec
files for each real-time system automatically.
© Commonwealth of Australia (Geoscience Australia) 2011
System Monitoring (cont)
© Commonwealth of Australia (Geoscience Australia) 2011
System Monitoring (cont)
© Commonwealth of Australia (Geoscience Australia) 2011
System Monitoring (cont)
© Commonwealth of Australia (Geoscience Australia) 2011
System Monitoring (cont)
© Commonwealth of Australia (Geoscience Australia) 2011
Development process







Tools and technologies don’t do much alone.
They exist to support a process that ensures they are
effectively put to good use.
A development methodology is this process.
We follow an Agile methodology, loosely based on
Scrum.
Regular, planned release cycle or “sprints”.
Items of work are assigned to sprints.
Unassigned items are used to plan next sprint.
© Commonwealth of Australia (Geoscience Australia) 2011
The Future






Redevelopment of all ATWS software, including new
DSS which will be a major undertaking.
Possibly move to Python as our main development
language.
Migrate to Apple Mac or Linux in next few years.
Array processing.
New magnitude calculators.
Regional responsibilities.
© Commonwealth of Australia (Geoscience Australia) 2011
DSS Redevelopment


New heads up displays.
More information – answer the most common
questions of visitors:






When was the last Earthquake?
Who is on duty?
When was the last alarm/alert sent?
What did the PTWC get for this event?
Less distractions for duty officer.
Extra information sources, such as Twitter.
© Commonwealth of Australia (Geoscience Australia) 2011
DSS Redevelopment (cont)
© Commonwealth of Australia (Geoscience Australia) 2011
DSS Redevelopment (cont)






New “orbevents”.
Much greater functionality.
Seismic awareness, i.e. show detections on map.
Less clutter, focused on primary mission.
Timeline – clear indicator of how long left to make
decision, and when different events occurred (origin,
magnitude, etc).
External data – Twitter, felt reports, external solutions.
Increase situational awareness.
© Commonwealth of Australia (Geoscience Australia) 2011
DSS Redevelopment (cont)
© Commonwealth of Australia (Geoscience Australia) 2011
DSS Redevelopment (cont)
© Commonwealth of Australia (Geoscience Australia) 2011
Python




Perl has been main language of choice.
My background is in Perl.
So why even think about Python?
Actually lots of reasons, but 2 main ones:
Finding good Perl developers is hard. Really hard.
No-one wants to learn Perl – existing Perl
developers want to learn something else!
 Lack of bindings to modern Graphics Toolkits.

© Commonwealth of Australia (Geoscience Australia) 2011
Python (cont)





We expect the new DSS to rely heavily on advanced
graphics manipulation that need canvas like
functionality.
Gtk+, does not have a native canvas element.
An extension, Goocanvas, is available, but Perl bindings
are incomplete compared to Python.
Also, most modern cross-platform Toolkit available,
Qt4, has no Perl bindings but excellent Python
bindings.
Tk? Possibility, but seems like a step backwards.
© Commonwealth of Australia (Geoscience Australia) 2011
Python (cont)

Other benefits:







Simply, easy to read and maintain.
Can focus on the problem, not the language.
Becoming the worlds de facto standard scripting language,
bindings to just about everything.
Great, active worldwide community. Particularly in scientific
communities, including seismic ones (obspy).
Large developer community within GA.
Amazing range of first-rate libraries: numpy, scipy, matplotlib,
obspy, PyQt4, PIL, and many more…
No (or little) dependency hell.
© Commonwealth of Australia (Geoscience Australia) 2011
Python (cont)

Issues?






Antelope bindings, unclear future.
Multi-threading – works but issues (the (in)famous GIL).
Staff retraining, recruitment
Overall we think that the benefits speak for themselves.
Have already started prototyping application for the
new DSS in Python using Kent’s contributed Python
bindings for Antelope.
Settling on the Qt graphics framework in combination
with Python.
© Commonwealth of Australia (Geoscience Australia) 2011
Python (cont)
© Commonwealth of Australia (Geoscience Australia) 2011
Mac vs. Linux





Big question running through the Antelope community.
Antelope on Solaris has been EOL’d (2013), future
Linux support uncertain.
We have a corporate preference for Linux, as it plays
well in an Enterprise environment.
Lack of Mac expertise, and questions remain about
how Mac’s can operate in a data-centre context.
Redundant power supplies, LDAP, SAN, Lights-out
management (LOM), virtualization, updates.
© Commonwealth of Australia (Geoscience Australia) 2011
Magnitude Calculators





We currently have customized Ml, Mb, Ms (Msx)
modules running under orbevproc.
We also use the standard AutoMwp calculator.
CMT process works outside of orbevproc (trexerpt).
Want to develop MT, Theta, MCoda, WPhase, etc.
New orbevproc model for running these modules:



Let orbevproc gather, filter and process waveforms.
Write to SAC files, manipulate SAC headers.
Call external “black-box” module to run against SAC files.
© Commonwealth of Australia (Geoscience Australia) 2011
Questions?
© Commonwealth of Australia (Geoscience Australia) 2011
Download