Return

 

 

UNITED STATES DEPARTMENT OF COMMERCE

 

Moderator: (Berchoff)

March 25 2010

11:30 a.m. CT

 

 

Operator: Good morning, my name is (Janis) and I will be your conference operator today. At this time I would like to welcome everyone to the National AWIPS roundtable conference call. All lines have been placed on mute to prevent any background noise. After the speakers remarks there will be a question and answer session. If you would like to ask a question during this time, simply press star then the number one on your telephone keypad. If you would like to withdraw your question press the pound key, thank you. Mr. (Berchoff) you may begin your conference.

 

(Berchoff): Well thank you. Welcome everybody; I'm glad you're able to join in today. Today's objective is to be brutally honest with you all out in the field about what's happening with AWIPS II. I know that there is, you know, lot of word out there in the street and a lot of conflicting messages that are reverberating across the national weather service about the stability and the status of the program. I thought it was important that first off I had the opportunity to give you what I know today about AWIPS II and then allow people to ask question.

 

I really am looking for the hard questions because I really do honestly believe that while this is a very challenging program and I'm not going to tell you any differently. This is a very challenging transition that we're making here from AWIPS I to AWIPS II. I also honestly believe that the progress that we're seeing today is actually satisfactory; I'm not going to tell you it's outstanding or superb or superior. I think we have a pretty good handle on the challenges that we're facing and I think we have a path forward to try to mitigate the effects as well as possible on the field.

 

First before I get into any specifics about AWIPS II, I want you to know that I myself am a field forecaster. I spent many years in the air force. I worked in weather stations. I actually built a regional weather center that was a bit predicated on an infrastructure that was very similar to your AWIPS infrastructure. I understand how this system and other systems are the lifeblood of our industry. I know how critical it is that these work properly. I know how frustrating it gets when they don't and I also understand that performance of the system, speed of the system, the number of button clicks of the system, all those things are very critical in helping you be efficient enough to do your job well especially under some very trying conditions when the weather is going bad on you and you have five or six people in the weather forecast office just trying to keep up with what's happening around you. The last thing you need is a system that is not going to produce what it needs when you need it.

 

So, I've been there, I've been involved in two fielding of systems in the past on the air force side. Both of them did not go well. The second one when I was the hub commander, when I was the regional commander I had probably a 150 different flying customers out there that we lost our systems for 12 hours and when I took this job over almost a year and a half ago, the one thing I promised is that I would never forget those experiences and I would do everything I can in my power to try to prevent that from happening.

 

So just to let you know the approach we took to developing and testing this system, when I came onboard there were several folks that came up to me and mentioned to me their concerns that, you know, we were doing this black box conversion from AWIPS I to AWIPS II and what's important to understand is that the main gains that we're going to get from AWIPS II initially are really in laying an underlining infrastructure, a services oriented architecture that is going to give us a lot of flexibility, extensibility in the future. It's going to allow us to become more interoperable with our customers to bring data in from their systems into our systems, to setup better tools for helping us to alert and to monitor and it was going to give us the flexibility to move forward into decision support services era.

 

It's going to allow us to do things like not be totally dependent on the SBN so when the RUC, 18 hour RUC comes out of NSEP and we don't have the bandwidth in the SBN that's not going to prevent you in the future at some point from getting that data via other means using the (SOA) architecture. This is going to give us flexibility like we never had before.

 

The second thing I want to say is that it's going to improve our ability to do development within the AWIPS framework. I know we had an initial feedback from one of our (FID) members who said that he was working on Python during one of these integration tests and mentioned that it was easier to work in Python in AWIPS II than it was in AWIPS I and we're only looking at building that development capability so we can reduce the problems with having to develop codes somewhere else, importing it in and doing all those kinds of things. So there's a lot of power that's going to come from taking on this transition and in order to reach the promises of what this system is going to allow us to do in the future it's going to require us to go through some of this pain in this transformation.

 

Now when we get AWIPS II out to the field next year, early next year it's just going to be basically a black box conversion. You're going to have all the same functionality that you have today. The whole idea is to make sure it has the same look, feel to the forecaster. There should be very little disruption from that perspective in your forecast process. There is going to be a much more powerful backbone. It's going to have the same performance standards and if it doesn't I want to know if it's not performing to the same standards because that's something that I promised that we're going to do. I'm very dedicated to the quality of the software. This is not going to be a schedule driven fielding. If the software is not ready to be fielded it will not be fielded.

 

We recognize that there are challenges to that, the longer that we don't field this software the more time that there's a freeze on AWIPS I code and the more impacts that has to the field in terms of fixes that are in the pipeline. This is a tradeoff that we're working through right now but what I will promise you is that when we get the field OT&E I told my folks that I want field ready software and field OT&E. We're not going to send software out to the field that is not field ready.

 

Too many times in the past we put software to the field and it crashes, it doesn't work. I got a good example this morning of a build 5 in AWIPS I where the software was sent out to the field. It crashed the system for 12 hours and I believe it took it down for almost two weeks. Oh, 12 hours to install and two hours to recover two weeks to recover. If that happens on this watch, I will hang my head in shame on national televised DTC to all you folks out there because that is what we try not to see happen in AWIPS II.

 

Now what you got to understand is the steps that we have taken up here in order to frontload the testing, in order to ring out the software meant that we had to bring the field in earlier into the process so we've had a lot of pre, pre, pre, pre testing going on here in order to ring out the software that has exposed forecasters in the field to some of the what's in the sausage making. Normally you wouldn't see that, but what has happened is because folks have seen that the impression is gotten out that this AWIPS II is not stable, that it's crappy, that's it, you know, this is never going to work and all those things and they're right. When they were looking at that software in the state it was in it wasn't going to work but what we have done is, is we're frontloading these tests. We've done slices that we haven't done in the past with delivery. We have been doing more of these FIT testing. We actually are trying to ring this thing out to the max before we even get into system OT&E and field OT&E.

 

Now that's the strategy and my hope is, is that that's going to mean that when we get this out to the field, the fields OT&E it's going to be a smoother process, we'll see, you know, I could only tell you that I'm confident at this point that we are ahead of where we would have been in any other production field release in the past, but it does mean that some of you have seen some of the what's in the sausage making and I made the decision to bring into the factory to watch the sausage being made knowing that there was risk that folks out in the field would see the what's and assume that oh boy, here we go again, we're going down the same path as AWIPS I and there's a lot of culture and a lot of history behind AWIPS I that is definitely something I would be concerned about if I was in the field.

 

So I wanted to share with you first what our philosophy has been and what we're doing and why it is that people are seeing what they seeing out in the field in terms of the software. Now, first I want to share with you some of the most recent AWIPS II activities. We had a FIT test here in Silver Spring in March. We tested the latest AWIPS software code. We had three days of activities in that FIT and there was AD, DRs generated. I will tell you the most positive outcome of that FIT was that the system runs stable for the most part. There was some very short term crashes but according to one of the participants in that meeting none of those crashes prevented them from running a full test and that was the first time that ever happened. So, we actually have what I would say system stability right now is good and that to me is the big long pole in the tent.

 

The second area of concern will be the number of DRs and of course as they're running some of the functional applications in the test they're running into problems because there are discrepancies in the software and there's somewhere around 900 DRs right now I think on the system and those still haven't reconciled with Raytheon yet in terms of what we all agree is a DR that is going to prevent us from going into system OT&E, but what'll tell you is that all the functionality has been delivered, it has been we've run through it and we know now where the problems are and Raytheon has a team in Omaha that is working feverishly to correct those deficiencies and now we're at a point where it's more of a mechanical issue than it is a system stability issue or structural issue. We just got to go in there and continue to do the code fixes that are necessary in order to get that functionality running to where we need to get it running.

 

We did hold a Preliminary Readiness Review on March 10th and the purpose of that review was to look at whether or not the you know, to try to make a determination of when to enter system OT&E. Now as you all know originally we're supposed to enter system OT&E in March, March 16th and we made a decision to slip that to May timeframe based on what we're seeing in terms of the DRs and what had to be corrected before we went into the system OT&E. Keep in mind that I keep my eye on the my eye is on the Field OT&E which starts in November so, we I'm sorry September so we have approximately four or five months before we go into field OT&E and my again, my direction has been quality software in field OT&E that's field ready. So if it's not hitting that mark we are not going to even go into field OT&E so there is a lot of work to be done between now and September and I've been working very closely with the Vice President of Raytheon. We are on the phone almost weekly talking about how his team is doing in meeting our expectations and he even gives us feedback on how our team is doing in order to support them.

 

I will tell you that I've been very impressed with the folks who have been coming in to the headquarters and those working in the field to help us in this endeavor. There was no way that we would be where we even are today without the help of the field. I will also tell you that the headquarters and the centers and the field WFOs and the RFCs, we have actually saved our program about $4 million that we would have had to pay out because of the sweat equity that you are all doing in the field. So I want you to know that I know that this is a sacrifice that it could be frustrating and that, you know, there are days when you're probably on your wits end out there trying to help us and I want you to know I still need your help, I still need your dedication and your support to this project because I do honestly believe we're on a good path here and what we don't want to do is the fact that we came into the sausage factory together, you never get a chance to taste that sausage because of what it looked like in there. You can't let yourself be scared away at what we're doing right now. to tell you, for me it takes a strong stomach everyday to listen to the news that's coming in and for me not to overreact to what I'm hearing and just letting the smart people out there do what they need to do to make it happen and I have a lot of confidence in my team up here and I have a lot of confidence that the folks in the field are going to help us get there.

 

The last thing I want to talk about is the local applications and the localization. We actually went through a period here in testing where we actually localized the Stirling System successfully and that gave us a lot of confidence now again, when we talk about trying to get the systems prepared for fielding and for this localization. We believe that, you know, we're going to be able to we're going to have another test year for another system replicating another site and if that goes well we're going to have documentation out there in the second week of April for you to and that'll be available on the (Nick Lac wiki) for folks to be able to actually or heavily start the process of Mike reading over, local apps and we thing that it's going to be much more stable than what we have seen in the past in terms of that.

 

We also are hiring five other contractors to help the field in migrating local apps over. we understand how complex this problem is and how challenging it's going to be and how much works it's going to be for you in the field so I've told folks that we need to get the field more help so there'll be five more people working on that to help with the local apps migration.

 

So the way the schedule stands right now is we have talked about entering just a more time in the middle of May I will tell you that that's going to be a tough target, you know, based on the fact that we're finally getting some of the understanding about these DRs. I could see that you're potentially slipping maybe another two weeks, maybe a month but I also feel confident that once we go into system OT&E and once we go into field OT&E we will have rang out a lot of problems already with the system and my hope is and my strategy has been all along that we'll have a relatively smooth field OT&E which would be a little different I think than what we have always experienced in the past and that will be really the first telling sign. If we've really done something here different than we've done in the past.

 

One of the things that I'm focused on is not repeating all the mistakes of the past like, you know, you've heard that saying that, you know, repeating the same thing over and over again even though it doesn't work is a sign of insanity and I'm not quite insane yet although this program might put me over the edge on that, but we are hopeful on that.

 

Then we're looking at like we said, a field OT&E beginning in September that's going to be a day to day slip off, system OT&E slips and then we're looking at deployment early next year. We are also putting hardware, new hardware in now. Originally when I came onboard I think in the first day I was here they were telling me the plan was to not put new hardware in and to not have a parallel ops capability. I told them I wasn't comfortable with that, I've been there and done that it doesn't work all the time and now we're going to have new hardware at all the OT&E sites right, the field OT&E sites is that true (Tim)?

 

(Tim Hopkins): They should know about the schedules of the new hardware that's coming right so it's...

 

(Berchoff): Tim you answered my question?

 

(Tim Hopkins): Yes there is...

 

(Berchoff): OK.

 

(Tim Hopkins): ...going to be new hardware. I could list them if you'd like.

 

(Berchoff): No, no but the point is...

 

(Tim Hopkins): Not all new hardware but there'll be like four or five components that's coming out.

 

(Berchoff): Got you and it's the key components.

 

(Tim Hopkins): Yes right, the server is new, the new server the X1234 and the new power wall replacement, new workstations, new land switch those are all we're working hard to get those out there ASAP.

 

(Berchoff): OK and we also have rollback plans right that are pretty robust that we're working on. Do you want to talk about that one?

 

(Tim Hopkins): Yes that was some good news from the last FIT. This has been an unknown area about how easy and how quickly we could roll forward and roll back between AWIPS I and AWIPS II at the last bit the beginning of March that Raytheon demonstrated a rollback from an AWIPS II installation to AWIPS I and a roll forward from the AWIPS I to the AWIPS II and it was largely scripted and well designed and it took one hour, which was good news for us. It was tested and worked successfully so we're going to we're very encouraged by that. That's a big risk production for both sides we think.

 

(Berchoff): So my main point here is that we're not going into this just with this degree of hope that everything is going to work right. We're also laying a lot of contingency plans in place just in case some of these strategies that we think are going to help us be successful, something bites us in the butt so we're going to be ready to make sure we can fall back and do those kinds of things. Before I open the floor up to questions, there's one last thing I want to discuss with you.

 

When we get AWIPS II to the field not only are we going to be laying this architecture for the future where we can build on and build upon some of the future capabilities that we're going to need in order to move into an open architecture, (SOA) architecture, interoperable environment. We're also going to see some improvements that you may not be aware of. We're going to have single groovy for access to (D2D GFE, ABN, PFS,) (inaudible) etc and this should allow for quicker movement between these modules during severe weather.

 

We're going to allow simultaneous activities in GFE. The A2 GFE is multithreaded. It'll be able to perform simultaneous tasks within GFE that previously were serial. I know from my perspective when I used to work in the field that first of all, let me just say that I was shocked that you couldn't do this already all right. Now again, that to me coming in from the air force side and I'm not throwing stones at anybody here in the room but when I heard that we were that you guys couldn't do this I was flabbergasted; OK that's enough for the editorial comment but anyway, so you're going to have that ability. For example A1 has if you run any smart tool procedure you must wait for it to complete before doing anything else in GFE. A2 allows you to start the smart tool procedure and then go onto edit grids etc. So that means unfortunately a few out there there'll be less coffee drinking time.

 

There's also going to be less service backup downtime. We're going to have to serve clustering capability; we'll allow to reduce instances of service backup by allowing hardware installed in other system maintenance activities to be performed in a reduced performance mode but without having to going to service backed up. I don't know how long it takes you guys to work service backup but I can imagine it is a little bit of administrative work associated with that and of course we're always impacting others when we do that so I don't know, it sounds like a pretty good thing to me.

 

Google map zoom and (pan) use mouse and mouse wheel. In A2 this will be configurable by the user. The Google map way is more efficient and quicker once the user is accustomed; many people are already familiar with this new method from internet use. Then we're looking at a unified set of map backgrounds. In A1 site test to manually download and maintain separate map backgrounds for D2D, GFE and (hydro) and in AWIPS II they will all use the same map backgrounds. And then I think that the last thing I want to say is that I've been well aware of this issue with the RUC 18 hour and the fact that we can't get into AWIPS. I also am very aware of the challenges associated with having to work on multiple platforms in a forecast office of having to integrate that in your mind mentally, not being able to overlay and integrate information and what that, you know, does in slowing you down and, you know, one of the things that, you know, I'm very focused on is getting us to platforms that are, you know, multiuse platform and AWIPS II is going to allow us to do in daily delivery during one of our extended programs, which are going to happen right away although I've asked (Steve Shotz) to tell me what it's going to take to accelerate it is you're going to be able to go into other databases out there like NOMADS and pulling the data and bringing it into your AWIPS without having to go through the SBN and to me that is just the power of freedom. I mean that just to me that just unleashes freedom for the forecaster out there and I understand that and, you know, we're going to look at that and see how we can accelerate that, but that'll take away this problem of having SBN being a choke point for upgrades and things like that.

 

Finally, I challenge the team also to come with some recommendations on how we're going to become more agile in our upgrades and fixes on AWIPS II. I know that there's a lot of frustration out there that, you know, sometimes very simple software code changes, you know, they get put into the pile and into the queue and even though it could be something that could be three lines or code or two lines of code. It could take you six months to see it, we're looking at things like that. We need to be more agile in how we do business and I challenge them to do that and I've also challenged them to be looking at how we could do more prototyping and trying to write requirements for things that we don't quite yet understand what we want throw them over the transit to a contractor who is trying to, you know, not only are they trying to figure out what it is we don't want because, you know, we don't know what we want but then they take that and they don't quite understand even what we don't want and they give us something back that isn't even close to what we wanted and so we've now spent money, time, resources and a lot of frustration trying to deliver something and that's just not a paradigm that I can live with.

 

I told them that we got to figure out how to do that better and what I'm going to tell you is that I'm open to any suggestions in the field on how we can do AWIPS II extended better. I am wide open. I'm going to give you an e-mail address here. If you can't get on the line because there's just so many people that want to ask questions, you could send an e-mail to this address. Its olga.brown-leigh@noaa.gov and if you have any questions that you can't get through on the line today once I open it up here in a second, please send any suggestions you have for how we could do AWIPS II better, how I can use the power and innovation of the deals to help in this process, because one of the things that I'm really trying to harvest is the innovation in the field. We've done that through several programs already working (INWS) and also (IRIS) and we have a mechanism now where your innovations in a field will have an opportunity to bring to our level I'm open to that.

 

So with that being said, I think I've covered what I wanted to cover. I'm going to ask around the room here real quickly did I miss anything and then I'm going to open it to the floor. OK, I think that's what I wanted to say (Janis) if you want to start opening the floor up for questions and comments I'm ready to go.

 

Operator: At this time if you would like to ask a question press star then the number one. Again, if you would like to ask any questions press star then the number one. Your first question comes from the line of (Jay Smith).

 

(Jay Smith): Hi, this is (Jay Smith) in Fairbanks, Alaska. I guess I'm happy to hear you say that you don't want to repeat the mistakes of the past. Well, one of the mistakes of the past as far as I'm concerned is the OCONUS regions seemed to be treated as bastard stepchildren when it comes to software development in that software development tends to focus on making things work first in the CONUS then time runs out and then things don't work well in the (OCONUS) because there are things that are different in the OCONUS things like we don't use Lambert conformal, we use Polar Stereographic Mercator, our side identifiers are different. We straddle the dateline and we have issues like that that are still that are cropping up in AWIPS II much like they did in AWIPS I and so I have concerns that the OCONUS is going to be left behind again and we're basically as far as the OCONUS is going to go is that we're going to repeat basically all the mistakes that we made in AWIPS I. I could go on but I think I'll stop there.

 

(Berchoff): First of all that's an excellent point. Coming from an air force background we had the same challenges in the air force. In fact when they launched the first F20, the new F20 airplane with across the dateline all its systems went dead on it and they had to do an emergency landing. So, I know you spent, you know, see I don't even know how many billions of dollars on an airplane and then it crosses the dateline so I hear you. You know, I also understand that, you know, these are very good points first of all and I'm glad that you keyed me into them and reminded me of the challenges that you have over (CONUS). What I will tell you is that my staff tells me that because of the flexibility in AWIPS II making fixes like this if there are needs to make fixes and we need to I need you to, you know, let us know what in AWIPS II that we're seeing right now that is concerning to you and make sure we're not missing it and I'm going to have my guys reach out to Fairbanks and make sure we talk with you because you've given us a fair warning now so we get no free lunch (Tim) when we screw this up. But what I'll tell you is that the flexibility in this system is going to help us I think be more responsive to changes like that.

 

Now let me ask you (Tim) a question. (Tim) are we going to be able to run a FIT using a configuration from OCONUS locations?

 

(Tim Hopkins): Well, if you recall last year we had one.

 

(Berchoff): OK.

 

(Tim Hopkins): So the answer is yes and the OCONUS when the calls out come out for FIT participation it includes OCONUS OK so, the fact that you know some of the problems already means that you're participating...

 

(Deidra): Are you documenting this?

 

(Tim Hopkins): Documenting them, which is good. I think that some of the things advantages that AWIPS II has is the flexibility in the localizations it helps (OCONUS) right. Being able to configure to essentially, you know, a Google or underneath you essentially have a Google kind of environment and so that helps us and those localizations can be generalized to those areas much more easily. That's one area in the infrastructure that I think will help a lot. We've got a lot of trouble with that, you know, being flexible in the past.

 

(Berchoff): This is good though. I'll tell you I have a couple of worry points and I keep my folks focused on it. One is the river forecast centers because I know that, you know, I don't have all the baggage of weather service that everyone has. Everyone tells me, everybody wishes to get the (inaudible) and I say I don't understand what you're talking about to me, they're part of the family I grew up that way only, you know, I got here a year ago and (Gary Carr) beats me over the head all the time. So I worry about them, I worry about the CWSUs and what I did was I asked my team today to we were talking about CWSUs earlier and we I asked them to tell me what I need to do to ensure that the bandwidth that's needed to get into the CWSUs in the future so they can get the full use of AWIPS II and even though what I have to do in order to make that happen. Then I worry about the OCONUS locations, which is (inaudible) was here so you're right we got to keep our eye on the ball because it's not the everyday things that, you know, we do OCONUS that are going to probably catch us with our pants down. It's going to be those unique missionaries that we needed to keep our eye on.

 

Male: Participate in the FITs. You know, ring it out, document the problems we'll get them fixed. You are right, there will be everybody else participating on an equal partnership.

 

(Berchoff): Great. So we have an all expense paid trip for you from Fairbanks to Washington DC, you'd like to do that sometime. All right, thanks for your question, comment and your concern. (Janis)?

 

Operator: Your next question comes from the line of the Tallahassee Weather Center.

 

(Berchoff): Tallahassee, you're on the air?

 

Male: Can you hear me now?

 

(Berchoff): I can hear you now good. I thought you hung up on us?

 

Male: No, I'm sorry. My question is, I heard some rumors that we're still going to be using 32 bit operating systems. Are we going to be using the more powerful 64 bit?

 

(Berchoff): Initially it will be with the 32 bit. The operating system will be migrated to 64 bit on its own schedule, but yes we will, you know, the operating system will have a schedule of its own but the initial will be 32 bits. We will move to 64 bit kind of with the Red Hat I mean I know Red Hat is already 64 bit but we don't have exact schedule yet but we will move to 64 bit. The hardware supports it already.

 

Male: I'd like to see that as soon as possible. I mean we crunch a lot of numbers here and 64 bit would be the logical goal for that so anyways.

 

(Berchoff): So I'm going to ask (Tim) to tell me when he thinks we're going to be doing that by?

 

(Tim Hopkins): OK.

 

(Berchoff): Right. So, we owe you that answer that's an action item back to the group, good question, thank you. OK (Janis).

 

Operator: Your next question comes from (Todd Holston).

 

(Todd Holston): Can you hear me.

 

(Berchoff): Yes Todd.

 

(Todd Holston): I got a simple question and it deals with when we do this field office OT&E in September, are we going to have the new hardware platform or are we going to have to use this on the legacy hardware platform.

 

(Berchoff): You're going to have the new hardware platform.

 

(Todd Holston): OK that's it thank you.

 

(Berchoff): Thank you. OK (Janis).

 

Operator: Your next question comes from (Joe Nimes).

 

(Joe Nimes): Hi this is Joe in fabulous Las Vegas. My question centers around service backup and it's a two parter. One, any considerations when this does get deployed for service backup between service backup payers etc, is that in the plan and I didn't hear it. And the second is, after, in AWIPS II does service backup change. are we going to leverage things like virtualization and I heard you talk about server clustering, if you could elaborate on both of those topics inside of service backup, I'd sure would appreciate it. Before I turn it right back over to you, service backup right now is a disaster, it's a mess it barely works in my opinion of course and I would sure like to see that addressed.

 

(Berchoff): OK, I'm going to let (Tim) respond to that.

 

(Tim Hopkins): Well service backup is an area of concern right now where we haven't done a lot of good end to end testing on service backup or haven't been able to yet, OK. So, I could tell you we're not using virtualization yet at this point. That kind of goes along with the 64 bit migration in some ways because we have a we're doing our Red Hat contract years this year with the renewal with the three year renewal of the Red Hat contract, both the 64 bit and virtualization technologies we will be including those OK in preparation for those migration activities and the use of those new technologies. We won't get that right away. Service backup, you know, right now for better or for worse the plan again is black box in that regard. We're just trying to get it to work the way that it does now and to support the operational needs now but there are a lot opportunities with the new infrastructure to improve service backup in the future with this infrastructure because of the flexibility of the services oriented architecture.

 

(Joe Nimes): All right. So I guess question then is, are we do we understand the challenges right now with service backup up here at the headquarters well enough. I mean if I was to ask you to write requirements for improving service backup under AWIPS II with an understanding of what the new architecture is going to be providing, I mean can we do that yet or I mean where are we?

 

(Tim Hopkins): Well in that regard from my perspective no we don't have a, you know, new set of requirements for service backup for the future that I'm aware of. That would the the process for that would be, you know, in (OSIF) project that would define those requirements.

 

(Deidra): I think, I mean I think we're getting close to being able to doing that. I believe there are already some of the projects out there to improve service backup and they get better and my work with Raytheon that I've done I've seen places (suitable) so we can start to improve service backup once we get AWIPS II out the door and we're able to start going through it to take advantage of some of the architecture as well as the new technologies that they're going to get because of the 64 bit and so forth later. So I think we can start laying out the plans that we know is kind of what the requirements are. We know what the problems are in AWIPS I at this point in time.

 

(Berchoff): All right so what I'm going to do is like, you know, obviously I can't promise you that we're going to have service backup improvements during the initial fielding of AWIPS II but I promise you that we will start looking at this now and getting ahead of the problem so that when we have the opportunity to begin implementing changes we are not starting, you know, our planning process a year from now but we're starting it now and hopefully that will help accelerate, you know, what would have been something that could have taken longer. So I appreciate that was a very valuable input and I hope that satisfies you for now.

 

(Joe Nimes): Thank you, I'm glad that you heard me.

 

(Berchoff): OK. OK (Janis).

 

Operator: Your next question comes from the line of (Rob Turowski).

 

(Berchoff): Rob? Are you on mute Rob? I can't hear you. Hello?

 

(Paul Bandrowski): This is (Paul Bandrowski) so maybe they got it a little wrong asking the question.

 

(Berchoff): OK.

 

(Paul Bandrowski): If nobody else is going to jump in I'm going to take their slot.

 

(Berchoff): You got it.

 

(Paul Bandrowski): All right. In AWIPS I there is currently a lot of open DRs and this is software that is not even slated to be fixed and so how are these DRs going to be transferred over into AWIPS II? For instance a lot of applications are being wrapped by Raytheon and are not actually being reported. One of the major ones is climate. Climate has a lot of outstanding DRs. There hasn't been any DRs worked on climate for a long time so what is going to happen in AWIPS II?

 

(Berchoff): That's a very good question. We're going to let (Ed Mandel) answer that one succinctly.

 

(Ed Mandel): Right we know we have those and you're right and because we wrapped parts of the code we brought those DRs along. I think our plan is once we get into AWIPS II and we deploy the migrated versions is to look through those DRs and determine what our priorities are as far as those and to start going through those using the DR team the way we have done that in the past. We probably need to do that at a more accelerated level but it will probably have DR from our existing migration putting that out plus those little backlog DRs. So we have been talking about how we want to kind of try to work those off and get to the point ultimately where we don't have a continuous backlog of 400 or 500 DRs and get that down to a much more manageable number, but that's not something that's going to happen initially and so yes, but we're taking along the (thoughts) available to us initially and then working those DRs and prioritizing those so that we can fix the ones that are important and hopefully do more than we've been able to do in the past.

 

We hope in the re-engineered code in the wrapped code we will almost certainly be carrying those DRs forward. In the re-engineered modules, they are not necessarily in other words we're not coding defects just to replicate, we're not replicating defects intentionally OK. So one of the advantage of the re-engineering is we would hopefully eliminate backlog DRs in those areas.

 

(Paul Bandrowski): What percent of the code is seen (just wrapped) would you say, well best estimate. Can't answer it?

 

(Berchoff): It's more broken down into functional areas like, you know, something like climate or something like NWRWAVES and I think maybe at FSI or something is what also...

 

(Inaudible).

 

(Ed Mandel): I think a lot of the decision (that has been stopped) is more wrapped. Some of the high grossed has been wrapped and the things you mentioned the climate and hourly weather roundup has been wrapped so your right Paul it's more like in the functional areas than it is, it's hard to describe system wide.

 

(Deirdre): And I will add to this. We also have yet another planning activity that we need to do to take that wrap code and figure out how to what's the password, how to integrate it in. The (inaudible) piece of code but chips are coming in and is going to replace that piece of code but we don't want to be doing anything in the architecture with that piece of code at this time. (River Pro) is also a wrapped application but we're doing a project of (IDS) right now to try to replace our warning so we're not going to do anything specifically with that. (Inaudible) roundup we need a password to how to get that integrated into the system.

 

(Paul Bandrowski): OK.

 

(Berchoff): All right so not a great answer. I hear that and I know, you know, one of the big challenges that we have is our resources, you know, obviously, you know, no whining I mean it is just what it is, you know, and we have to make (probably take some) decisions. What I would say is that if there is a DR though that is a real problematic DR we need to make sure that gets up to the, you know, we get that worked up to the priorities at the top of the list and we work as quick as we can, you know, and I think hopefully you're working with the field to understand what those are and, you know, we work to get those worked down so all right well thank you for your question, that was a good question. I wish I could give you a better answer. (Janis)?

 

Operator: Your next question comes from the line of (Mark Keane).

 

(Mark Keane): This is Mark down in Houston. We're slated to become a field OT&E site in September and one of the offices we support is our CWSU up at Intercontinental Airport. What provision is there for the CWSU, would they still be the current architecture they have is pretty dismal in performance.

 

(Berchoff): Yes we talked about that this morning a little bit and I'm going to just try to answer point to that and then I'm going to hand it over to (Tim) for him to correct me on all of the things I say that aren't right. My understanding is that main challenge is going to be the bandwidth between the (WFO) and the CWSU. They tell me it's a T1 line and it's paid for by the FA, correct. So, I've asked them this morning, I said if that's going to the long pole in the tent you're going to need to look at, you know, how do we get a better bandwidth between the two sides and how do I make that happen.

 

Now I think for OT&E the CWSU at Huston going to get one also at that point, is that the plan Tim?

 

(Tim Hopkins): No the CWSUs won't be getting AWIPS II - they're not in the scope of the OT&E directly though they will of course they'll sort of be treated like a local app, you know, and that's it. They have to continue to work obviously and all the interfaces that they use to get into AWIPS need to work but, you know, we're not deploying the AWIPS II software to the CWSUs with the initial deployment.

 

(Berchoff): Now keep in mind, the CWSUs when we do launch the AWIPS II and this new open architecture system and flexibility and this new way of mapping, you know, there's going to be things that they'll be able to do that in the past you may have had to do software changes, you know, for but here you'll be able to just do your localization for whatever area the CWSU is focused on and build your, you know, capabilities from there. So, I think and again, correct me if I'm wrong, but I believe that the long pole in the tent is the comps not the it will not be AWIPS II is that a true statement?

 

(Mark Keane): I would agree with the comps issue. In the past we had dealt with it by runningD2D on their end and just sending the data over and that worked until we got up to the OB9 (boards) and currently they're having to export an ex-Window session from one of our LX board stations up to their end. With AWIPS II when we're in the OT&E will they be able to export a display or I'm currently I've experimented with that and had no success with getting AWIPS II to transport properly between workstations.

 

(Tim Hopkins): Yes that has been an area that we've been tracking for a long time. The export displayed those not completely working, partially works but it does not completely work because of the AWIPS II coding.

 

(Mark Keane): That's what I ran into. As a possible solution what about running (LDM) to just use the T1 line to ship data across and to run the server and display software on their end.

 

(Tim Hopkins): Those are the kinds of solutions that we would have to explore. Then again, we really need more bandwidth though.

 

(Berchoff): Yes we do and the T1 we've measured the bandwidth and they're not getting through T1 performance out of it and we're not sure why but since it's an FA circuit they're also a little bit up against a roadblock on troubleshooting.

 

Male: Exactly.

 

(Mark Keane): All right. Well, this is all good and I'm going to have my office my guys contact you and talk a little bit more about this issue, you know, the CWSUs are not going to be second they're not going to stepchildren and we're going to make sure that we do what we have to do in order to ensure they could do their mission. And if there are things that we can do to help mitigate the lack of bandwidth then we need to make sure that and especially if you had a workaround before that is not now available to you we got to make sure that workaround is available under AWIPS II, you hear that.

 

(Berchoff): And then I want to work the bandwidth issue. I think we've got to go after that because otherwise we're just going to be continuously in the same problem we're in right now. Now I have to agree, T1 lines are generally pretty robust. So, I find it interesting that you mentioned that you're not getting through T1 out of that, that's interesting and again, I wonder if we could get out CIO guys and others to help.

 

(Ed Mandel): We have worked that in. I think there is our accounts guy (Jamie) has tracked down their counterparts and...

 

(Berchoff): All right. OK, thank you. (Janis)?

 

Operator: Your next question comes from the line of (Mike Magsig).

 

(Mike Magsig): Hi this is (Mike Magsig) from National Weather Service Training Division. I noticed you were mentioning the local application migration another component of things that kind of go along with the software releases and development is training and I was curious to know what's your high level commitment to having training for field OT and the operational release and specifically kind of a follow on question to that is what's your commitment to providing enough time for the training development to occur if we're not able to provide complete documentation in the working software in time for training to be developed, would you consider slipping the field OT&E kind of like with that and with the local application migration.

 

(Berchoff): Well I'm going to let (Tim) answer specifically to training but I do want to say that I meant to talk about training in my remarks and I forgot and I thought about and said I got to talk about training because training a lot of people think training is forgotten piece of every new system migration in fielding and I'm very big on the training side and I'm very focused on it and I'm very concerned about making sure we don't short change training so I want you to know I'm committed to do whatever I need to do to ensure training does not get, you know, short swifted on this but now I'm going to let (Tim) answer the specific questions about what we're doing with training and how we're going to make sure that there's time to prepare all the documentation for the training and I'll also tell you that we've had a representative from the training center heavily involved in the FIT testing also, which has been a good thing, so anyway Tim.

 

(Tim Hopkins): We've been paying a lot of attention to this recently. We know we've been told explicitly we know how much time is necessary, the training division has told us the training center has told us how much is necessary to prepare each of the modules necessary to prepare each of the modules necessary for the field OT&E. OK, so we have that built into our schedules. It is very tight. We've had issues with the (TO11) contract vehicle not providing the sufficient documentation. It was not in that (task score) scope so we spun off a separate contract vehicle that we're just now trying to get on contract as we speak and that would provide the level of effort necessary to get the documentation in shape in the way that the training center needs, that's one part OK. So that's how we're addressing the insufficiency of the documentation the (TO11). We're going to do that separately.

 

The second part is it is in the critical path OK. The training has to be there. We know that, we've known that from the beginning OK so there are a number of those - there's a lot of things in the critical path but the answer is whether you like it or not (Sean) yes if it's not ready we can't keep the schedule.

 

(Berchoff): Right so we're willing to we are willing to shift the schedule.

 

(Tim Hopkins): Yes.

 

(Berchoff): Right. So this gets me back to my initial my original discussion in the beginning. We want to have quality software fields in and we want to make sure that people are ready to use it and training is a critical component of that. Now what I'm going to tell you is that whether we slip a schedule or not that's not my decision, all right I'm willing to do that I want to do that but you all understand what the implications are of slipping the schedule and the implications are that we have to continue to hold off on fixing some of the AWIPS I issues until we get, you know, this thing fielded and I'm fine with that. But I'm going to tell you I'm going to listen to what you guys want in the field. I personally think it's worth, you know, to make sure that everything is lined up and we have a good fielding but it's really about how you all feel about it in the field and, you know, you need to get that information through your mix and hicks and up to your region and get us the feedback on as we run through some of these more difficult challenges later if we have to slip.

 

Now I will tell you that, I do not want to slip to schedule if it's preventable but I'm willing to do it. We are going to do it if we're not ready so, you know, it's a fine line there. We're pushing hard not to do it but if we have to we'll do it. (Janis)?

 

Operator: Once again if you would like to ask any question press star then the number one on your telephone keypad.

 

(Berchoff): OK so we actually have run out of questions, this is amazing. All right, who is the maddest person out there? I want to hear the maddest, all right talk to me. I want to hear, you know, give me something that's going to make me, you know, really sweat in my chair all right because, you know, I want to take on the toughest challenges. I will tell you that I know the culture and the history and I don't want to have I don't want to put on an optimistic face that I can't, you know, deliver exactly that may result I mean not delivering exactly what it is you all expect and I will tell you that it was up to me, you know, I want this to be perfect but it's not going to be perfect, but I will also tell you that we got to remain positive through this. If we get through this when we get through this, it may be painful but when we get through it we're going to have a capability that's going to be a gift that's going to keep giving.

 

It has so much potential for the future in our decision support services in building new applications down the road to improve our ability to provide assistance to the forecaster to do or alerting help us manage the myriad of things that you have to worry about on a shift and also I'm working right now with an innovation center down in North Carolina, it's the Renaissance Computing Institute, you can all look them up its in the Google it; just don't do it from China.

 

But anyway, so you Google it and you'll see that this is an innovation center that is working very closely with the Emergency Management Community in North Carolina, they're funded by the state of North Carolina and their mission in life is to improve the effectiveness of the emergency managers. Now, what I'm looking at is not only how we try to approve AWIPS and the tools and the capabilities that are going to be necessary in order for us to take on the challenges of increasing data flows in the future and helping you in your decision support as that grows and as that mission grows, but also on how you're going to communicate and collaborate with your customers out there. we're working on a pilot project right now to try to use them as an innovation center in the area of decision support services to see if we can bring some next generation tools out to the weather station here in the next five years that will allow us to jump a generation of technology and see if we can have, you know, an environment that's more hands free, that has some voice recognition so you don't have to have a phone, you know, number in your head and plugging that in and all that and trying to, you know, and collaboration tools that would be more touch screen and things like that to try to really move the weather forecast office into an environment where collaboration becomes easier and so we're looking at that also and what AWIPS II is going to allow us is going to give us the environment and the tools that we need and the capabilities to help us move into that environment seamlessly.

 

So I guess where I'm getting at here is that this is going to be a little painful but I think we're all going to be happy with it in the end. (Janis), could you tell me if there are any other questions out there?

 

Operator: You do have a few questions.

 

(Berchoff): OK and we can extend this a little longer. I have some time on my schedule.

 

Operator: You have a...

 

(Berchoff): So...

 

Operator: Go ahead. You have a...

 

(Berchoff): So anyway I'm ready for the next question.

 

Operator: Your have a question from the line of (Kevin Brines).

 

(Kevin Brines): Yes will there be a way for the forecasters to convert their AWIPS I procedures to AWIPS II?

 

(Berchoff): That's a good question, (Tim)?

 

(Tim Hopkins): These are the (inaudible).

 

(Kevin Brines): Yes.

 

(Tim Hopkins): Yes that's the area right now that is a manual process, OK and right now we expect that to be the most level of effort. You can convert them but you have to, you know, do it, you have to (fat finger) it in. You have to take your procedures and convert them manually into type them into the new framework. That's where we think is the most level of effort on the, shall we call it the local customization site configuration area, unfortunately at this time. we've been looking into, you know, ways to help automate that and stuff but I can't promise right now that we have, you know, an easy automated way to do that, it's a difficult problem that we don't have an automated solution for at this time.

 

(Kevin Brines): What makes it a difficult problem, just curious?

 

(Tim Hopkins): It's the difference in the infrastructure, you know, under the third between the two systems. OK, this is an area where it's an under the hood issue and that difference, you know, there just isn't an easy way. We have had GST looking at that to some, you know, and we have some ideas but we just I just don't have an automated solution at this time.

 

(Kevin Brines): How long will it take somebody or some people to do this conversion thing?

 

(Tim Hopkins): Oh boy. There are a lot of procedures at sites.

 

Male: It's very site dependent. There are some sites that have thousands of procedures. There are some sites that have hundreds of procedures. We've done some, you know, off the cuff estimate of (inaudible) procedure made (comparable) but not all the procedures need to be converted, maybe there's some older ones that have built up that don't necessarily need to be there and by going through this process it might be a good way to filter out those (inaudible).

 

(Kevin Brines): That's a good positive spin but how long is it going to take to do it.

 

Male: Maybe I could throw in a number. When I first sat down and tried to figure out how long it would take to do that I think I came up with like 700 hours per site.

 

(Kevin Brines): Wow.

 

(Berchoff): That's significant.

 

(Kevin Brines): Yes it is. It's like two and half weeks of one person. OK, you know, I'll ask more questions about it. I do understand though the challenges of, you know, taking stuff from one kind of a system and, you know, we're talking about a pretty in-equated chassis here, but...

 

(Berchoff): We certainly haven't given up on the automation part, we're looking at it. I just can't say that we have a solution.

 

(Kevin Brines): OK.

 

(Berchoff): We know it's a lot of work and, you know, we're trying to find a better way.

 

(Kevin Brines): OK. Thanks for making me aware of that. I wasn't aware of that so I hear you. Wish I had better news.

 

(Berchoff): Thank you.

 

(Kevin Brines): OK.

 

(Berchoff): (Janis)?

 

Operator: Your next question comes from the National Weather Center in Binnington.

 

Male: Can you hear me?

 

(Berchoff): Yes I hear you.

 

(Jose): OK I've got two questions. One for development purposes; will there be another workstation say for the IT or (ESA) and then the second question is dealing with like a PR thing for the AWIPS II. Is there I don't know of a page but is there a page with screenshots, maybe video of showing how this thing is going to work so that people in the field, you know, forecasters, WCMs can see this?

 

(Berchoff): (Jose) I'm going to let (Tim) answer the question.

 

(Tim Hopkins): On the workstation side a clarification, are you asking are we delivering an additional workstation from the program to the site, is that what you're asking or...

 

(Jose): Well what I take it as is that they currently have five workstations so that's probably what AWIPS II is mainly going to be, am I correct in that.

 

(Tim Hopkins): Yes that's correct.

 

(Jose): OK. If we needed a develop right now what I can do is I can come in through another machine to get into AWIPS to run things and like GFE,D2D etc, to do my development work but with AWIPS II its hardware reliant so what I'm wondering is if there will be a development machine for the IT so in order to do that kind of stuff?

 

(Tim Hopkins): You should be able to configure any workstation you have now for development; well I shouldn't say any but most of them that you have are (inaudible) kinds of boxes that are similar that you pay with your own money right. Those boxes will be able to be configured with AWIPS II and the development environment and you'd be able to get into AWIPS II that way and do your development the way you do today, I'm not sure. There may be some misinformation or something about the ability to do that but we have AWIPS II running on various kinds of boxes or development in testing here and elsewhere so that should be doable.

 

(Jose): OK.

 

(Tim Hopkins): So the answer is no we're not giving you a piece of hardware but maybe some of the understanding about what you will be able to do with your current workstations is not quite true with AWIPS II so I guess we need to make sure we understand that.

 

(Jose): Right. So the Website, in the way that you describe it Olga, anybody correct me if I'm wrong, I don't think we have a Website that has screenshots and things like that on it. We do have a Website for the technology infusions in AWIPS II. We could add an area where we have screen shots in more of what does it look like but that's a good idea. I think that would help a lot of people in understanding how this thing works, you know. A thousand words picture thing so.

 

(Berchoff): OK we'll take an action on that, that's doable. OK (Janis).

 

Operator: Your next question comes from the line of (Mark Keane).

 

(Mark Keane): Hi this is Mark in Houston again. Another question I came up when I was demonstratingD2D to the forecasters is will the provision be added to run multiple D2Ds on a given monitor. Currently you can have D2D in a (cave) session and so I don't know if you can run multiple (caves) or if you can have multiple D2D in (cave).

 

(Tim Hopkins): You can have OK within (cave) you can have D2D. There is one perspective that's a D2D OK. On a screen you could run multiple (caves). I don't know that that's recommended or how that would, you know, perform but yes that's possible. So you could run multiple sessions of (cave) on a screen but not multiple D2Ds in (cave).

 

(Mark Keane): OK thank you.

 

Operator: Your next question comes from the line of (Key West).

 

Mr. Berchoff: (Key West) I might have to come down and see your AWIPS?

 

(Key West): Are you there, can you hear us?

 

(Berchoff): Yes I hear you.

 

(Key West): Actually our question was you've already answered it. It had to do with concerns about procedures locally so we'd, you know, it's already been answered.

 

(Berchoff): Yes not satisfactorily but answered but we're working on it.

 

(Key West): Thank you.

 

(Berchoff): Thank you. (Janis)?

 

Operator: Your next question comes from the line of (Christopher Jenkins).

 

(Christopher Jenkins): Hey (inaudible) you hear me OK.

 

(Berchoff): Yes got you loud.

 

(Christopher Jenkins): This is from the Hurricane Center. Before the AWIPS I, AWIPS II conversion started we have been playing around with GSC and that was not part of the black box conversion. Will there be some sort of mechanism once AWIPS II has fielded to be sure that GSC will work for the national centers.

 

(Berchoff): OK good question. (Tim) do we have a...

 

(Tim Hopkins): Again I'm not sure.

 

(Deirdre): The functionality at AWIPS I is the (inaudible) that way in AWIPS II.

 

(Berchoff): It's what (Steve)?

 

(Steve): I don't think it's what they're doing at the Hurricane Center is part of the office baseline of Geo Cities.

 

(Christopher Jenkins): Is not.

 

(Steve): Is there OK, well maybe I don't know what exactly you're doing I can say this.

 

(Christopher Jenkins): It's basically just large domains in GSC, you know, just kind of comes back to the OCONUS question where we have different domains, different projections that type of thing.

 

(Steve): Yes I mean I think again I would give the same answer to that, you know, I participated in the FIT if they have concerns in those areas I think that the larger domain will be handled much easier by the infrastructure of AWIPS II, but there would be questions about how to localize to whatever domain you wanted but I think the flexibility is there and much more sold in than AWIPS I so that part yes. If there's other issues I'd say, you know, get to a FIT and let us know what they are.

 

(Christopher Jenkins): OK.

 

(Berchoff): That's a good point, thank you and, you know, again we don't want to lose sight of the centers and their requirements and needs also. So even if they can't make a FIT I'd like us to at least look into his question and get an answer back to him.

 

(Deirdre): There are two things to remember also. The infrastructure can allow GSC to work at a national center if they (sign). We have to put that in and (inaudible).

 

Male: Oh yes absolutely.

 

(Deirdre): But the thing that they're trying are not based on...

 

Male: Right, right.

 

(Deirdre): So that's what we need to have that nuance and then the other thing is that for the national center AWIPS migration we have the opportunity to look at that, which is a separate effort.

 

(Berchoff): OK, well this is good and you know why because we have other center issues that need to be on our scope we need to get them on a scope although I do know you have a real crack an AWIPS to AWIPS conversion team down at (NSEF) led by (Michele) and, you know, if we also can get your concerns and issues to her she can also work with our AWIPS team up here but thanks for that. (Janis)?

 

Operator: Your next question comes from the line of (Nick Petro).

 

(Nick Petro): Good morning or good afternoon as it is now. Quick question, not sure if this is the right form for the question but I figured I'd ask it anyway. But back when we replaced our PX servers there were some instruction that stated we were to keep them for later side by side testing AWIPS I and AWIPS II and then I more recently saw a document and I don't recall exactly where but said that WFOs should have the (scat) setup by the summer, whether or not, you know, regardless of whether they were an OT&E site, which we are not and I was just kind of curious, is there an expectation for sites, for WFOs to set this up on their old PXs to be doing side by side testing even though, you know, they may not be an OT&E site.

 

(Berchoff): Yes Tim will answer that question.

 

(Tim Hopkins): Two aspects to that that I want to point out is the first one is yes we do have an expectation that WFOs, all WFOs will setup and configure what we call the (scat) platform. The second part of that was the scope of that has evolved a little bit. The original side by side mission was part of the mission and that has been de-emphasized and not to say it's not still part of a scope but the larger emphasis now is the (scat) platform is the place where you would do prior to install of AWIPS II that's the place for you to do your local apps testing and conversion and sight migration of, you know, your procedures and other localization customization so you would have platform in your office to do that before the AWIPS II install comes in so, that's the two pronged answer I guess, does that make sense?

 

(Nick Petro): OK yes that does. So essentially we're expected to have (scat) up and running by this summer. Is there a particular date or something that we need to have the running by?

 

(Tim Hopkins): I don't think we have a date like per site. I would also mention too that the as the (DX12s) are replaced we're going to ask you to keep those and use those instead of the PXs right I mean just because time has gone on. Those are better boxes so just FYI there.

 

(Nick Petro): OK thank you.

 

(Berchoff): OK thank you. (Janis)?

 

Operator: Your next question comes from the line of (Shannon White).

 

(Berchoff): Hi Anna.

 

(Deirdre): I think it's (Shannon).

 

(Berchoff): Oh (Shannon).

 

(Shannon White): I actually wanted to respond to one of the field questions, I think it was Binnington. The training division is putting together variant training that we're actually going to do much earlier than the regular training because it's going to be used during the (inaudible) forecasters on the difference between the AWIPS I and the AWIPS II platform and that is something if there was interest that maybe we could provide to a wider audience to kind of get people, you know, familiar to what I mean...

 

Male: That's a thank you Shannon. Also you might hook up with Olga and maybe help out with providing some of the stuff we talked about with screenshots and a little bit more.

 

(Berchoff): Is that the same Shannon that came up (inaudible).

 

Male: Yes that's the same Shannon.

 

(Berchoff): Hi Shannon.

 

(Shannon White): Hello.

 

(Berchoff): All you people out there need to understand that Shannon is one tough cookie and she's representing your interest like no other. I mean if you could have Johnny Cochran as your lawyer you would want to have Shannon up here doing your FIT so, you know, and I like that. She really comes in here and she really, you know, rips us apart so you should feel confident and send her, you know, kudos for what she's doing for you out there and you make good candy I hear Shannon, good. OK thank you Shannon. (Janis)?

 

Operator: Your next question comes from the line of (Todd Foisy).

 

(Todd Foisy): Hey this Todd from Anchorage Forecast Office. Up here we have, some of you may know we have (2GFD) domains, which take up an area almost as wide as the whole lower 48 and we got hundreds of procedures and smart tools like quite a bit more than I would guess most offices have and we're still dynamically changing them, you know, all the time and I guess my question is just if you could give us what sort of a time commitment this going to require for those (GFD) IPS focal points out there, you know, editing, what kind of modifications they're going to have to make to the code with all their local smart tools and procedures that may not be present anywhere else, thanks.

 

(Berchoff): We'll let Ed answer that question although he's thinking right now.

 

(Ed Mandel): I mean we've done the inventory of what the local apps are and (inaudible) should be included in that so we have an idea of what the inventory is and what the quantity is. We've been working with (GFD) to iron out the local application infrastructure especially on the smart tools side so that we make sure that that works. We also have the (NCLADT) coming with how to instructions so for specific smart tools there should be some guide there. If you have this kind of smart tool this is the type of change that you need to make to do that. So now you're going to ask me for the actual number. (Don) will ask me after I stop so I might as well come up with one now.

 

(Berchoff): You're finally learning.

 

(Ed Mandel): Again, it's highly variable. Because of the number of local applications that each side has I mean some have maybe 10, some have, you know, 30-40 that they're responsible for so I mean I can't, you know, I control that numbers but I mean it's very site specific and I can't tell you how long it's going to take, you know, to convert on the smart tool. I mean we know as we dig into the things and as we've been doing the acceleration it does take a little while to get them understanding of the smart tool and what it does and to work on the integration but we're hoping that we're building up instructions on the how to things that will make it easier for the folks.

 

(Deirdre): We also have the 22 that has to be done (inaudible) nine of which are complete and we can go back and do a forensics on how long it took them to do those and update that average time as they'd likely get more in so you get a feel for how long it's taking.

 

(Harry): This is (Harry), I want to make it clear to everybody that this is not an all manual procedure. We spent a lot of time and effort making this area as automated as possible, that you're old procedures will require as little work as possible. We have this is not similar to the procedure situation where it's an all manual process, but the numbers of these things are big also.

 

Male: So is there any way that we can at least give them an estimate so they know what to mentally prepare for and organize themselves for it.

 

(Berchoff): Yes why don't we do that because I think, you know, I know that expectation management is a big component of what we're trying to do. I know that, you know, when I was in the field we just wanted to know that was helpful. We knew we had to do something but just tell us what we thing the impact is going to be and then you can schedule in your mind, you can prepare people for it so it doesn't become such a negative when it hits, you know. The biggest challenge we're going to have is there's going to be plenty to complain about. I guarantee you that there's be no shortage of that and I'm willing to listen to it, I am and share in the misery with you and all that. But I think more importantly, you know, we need to try to recognize that there is going to be some work here. It is going to be frustrating. It is going to be painful and let's try to prepare ourselves with expectations and also to, you know, try to remain optimistic.

 

I guess, you know, the way I look at it is, there are a lot of past errors in AWIPS I, there has been a lot of horror stories about things that happened in the past. You're going to have more than enough to complain about on AWIPS II that you don't need to drudge those up, you know. I want to be graded on how we did in this particular delivery in production not on all the baggage that we're carrying with us from AWIPS I. I think it's very important and I will tell you that my metric is not very high in terms of what I'm asking my folks to do. Basically, if we do field (Ochiny) and the folks that are involved in a few (Ochiny) just say, you know, this wasn't as bad as I thought it was going to be that for me is a very positive metric because I know that the bar, you know, it's a difficult we're doing a difficult thing and I think if we can exceed your expectations even if everything doesn't work perfectly I think that's something that I can at least consider a win for us here at the headquarters because this is hard stuff.

 

But you also should know that we recognize and feel the pain and I don't let them rest here very easily. When I hear there's things going on in the field I tell them we need to feel the field pain, we need to feel it and then we need to work hard at trying to mitigate it where we can so that's my approach to all this. (Janis) anybody else out there? I think we'll take like one or two more questions.

 

Operator: At this time there are no further questions.

 

(Berchoff): Oh, we got (Jeff Craven) here who is the (inaudible) at Milwaukee sitting in the room with us today. Jeff you have a question or you have a comment.

 

(Jeff Craven): I was wondering in the AWIPS II architecture if a phase has been designed for local modeling efforts. Right now we go through a lot of hoops to not only process the local models but to give them sort of their (inaudible) with some curious if that has been the focus of future development.

 

(Berchoff): (Deirdre) you know the answer to that? (Steve)?

 

(Deirdre): I'll try.

 

(Berchoff): All right, (Deirdre) is going to try.

 

(Deirdre): So we know that local modeling is a need and we are looking at local modeling but we have not come up with an architecture direction for where we would run local models. There on the table are everyone can have space somewhere that local controls where they have their models execute that they initiate and control or they have it onsite running or they have (INSEP) run it for them but in terms of getting there about which is better and how we go about making that decision so right now we don't have a roadmap for putting something out. So like that conversion we didn't have it before, he's not going to have it when it was (inaudible) out but we do know that that's the need and capability that you desire in the architecture.

 

(Berchoff): It does open up your question does open up the policy question. You know, with the state explosion that we see coming down the pike, you know, I'll tell you, you know, (Gozar) in 2016 when it comes online you're going to be able to get like spot updates on severe weather every 30 seconds or a minute and a half I can't remember but it doesn't matter it's a lot. And that's going to be data that has to flow then you're going to have, you know, we're increasing our ensembles. We're increasing the resolution of our wrap, you know, they're coming out with the RUC replacement here as the higher resolution rapid refresh. We're looking at high resolution rapid refresh ensembles. We're looking at (NPOESS). We're looking at just radar that could actually, you know, do polling itself is a pretty large increase in data and then if we're going into phased array or we're going into an area where we have more integrated radar strategies where we starting to peel radar imagery off of commercial TV stations, my concern is that we're not going to be able to afford all the pipe stat and so what we're looking at what me and Deirdre are looking at is an architecture of a cloud computing kind of concept. These are concepts that are out there right now that we're looking into and we're using our innovation center as a vehicle to look at this.

 

I mean, you know, the bottom line is and I'm not stupid, I've been in the field and I know that, you know, when you're a forecaster you want to have the assurance that you can touch and feel your data on the server. You know, you want to just be able to put your hand on the server and just, it's there, if the rest of the world was to go away I still have my data and I could forecast in the next two or three hours without having to worry and I recognize that, but we're going into an era where we're really going to have to look at our architectures and see about how we're going to do a push pull, you know, when we have this services oriented architecture and we're talking about subscription services and we talk about push pull and we talk about cloud computing where you can actually run applications in the cloud versus locally, right there on the server. You know the bottom line is the requirement is when you push a button and it shows up that's the requirement and I recognize that and we can never go into an architecture that when you push the button it doesn't show up or at least it doesn't show up any less than it does today all right. I'll leave it there, but so this is the kind of things that we're really getting our arms around here and part of my job is to make sure that we are positioned where you do have access to what you need when you need it but it doesn't break us and it doesn't make us become so reliant on you know, so may systems in (soap) types and stuff like that. So, it's a good question and it's a policy question and we're going to be looking I will tell you that in Jack's perspective (Jack Hayes) and my perspective is we're looking at more push pull, smart pull, you know, push and pull versus sending everything down the pipe and where I would like to get to someday is your systems are smart enough to know what you need that day based on the regime that's setting up.

 

Wouldn't that be nice, I mean could you imagine like you know that you have a, you know, severe, you know, you're in the Midwest and you're having a, you know, severe weather regime background and it knows what it wants to go get and how often and it just pulls it in and then you don't need to get everything you just get what you need for that particular time and then when you do need something you ask for it and it comes, you know, that's kind of where we need to go so these are the things we're working on.

 

OK well I think we're going to wrap it up. First of all, I think we need to do this more often. I like to get your feedback. I gave you the e-mail address earlier and I'd like to get your feedback on how you think this session went. I'd like to maybe consider doing this again in May, maybe in the middle of May as we're getting around, you know, system OT&E time, see where we are. I'd like to take these action items and I want to get them out to everybody, you know, transmit them on your AWIPS II thing and then I want to make sure we follow up and we answer questions that we promise we can answer and we consider the things that we said we're going to consider and maybe do this again in mid May and open up the dialogue.

 

You know, it's a fine line, I don't want to paint a rosy picture because the picture is not rosy, you know, it's a picture, it's not a bad picture, it's not, it's actually a pretty good picture but that's all in the eyes of the beholder, you know, you ask somebody to look at a picture and tell them what you see and you can get four different perceptions right, five different perceptions. It's going to be hard but I think it's going to be worth it and I guarantee you the team up here is working very hard, very hard I'm very proud of the team that I have up here. I feel like we're in a good place in history with people we have and so we just need to keep gutting it through and working together and I really do appreciate the field support. Try to stay positive. If you really, you know, hear something that doesn't sound right, you have Olga's e-mail address I guarantee you she'll answer it. If she doesn't you write to me and I'll get it answered but let's keep the rumors down, let's try to get the facts and let's work together and try to bring the forecasting force with us and let's stay focused on the target, which is the field OT&E when we get there.

 

Again, thanks and we look forward to doing this again in the future. We're out here at the headquarters.

 

Operator: This concludes today's conference, you may now disconnect.

 

END