General:

Thanks to Bob for taking the time to think about the MOOS project and putting together this report and thoughtful comments. His expertise as an embedded software developer one of many good perspectives needed to look critically at what we're doing. It is valuable to have a starting point for (or at least an input to) a technical dialog on MOOS.

This is a very technical commentary. I think it's best context is in a detailed technical review of SIAM and MMC.
The critique includes a lot of comments on MMC; I think that MMC team should see it and comment before it is distributed. Perhaps the title should be changed to something more general and accurate ("Systems Engineering of SIAM and MMC") and the sections be separated by sub-system (some comments on MMC seem to be directed at SIAM).

I think that there are some good insights here, and that some of the comments are skewed by an incomplete understanding of MOOS, the problem space that it addresses, and the resulting requirements for MOOS.

A number of comparisons are made between MMC/SIAM and OASIS3; these aren't valid, in my opinion, since the two systems are targeted at very different applications.

A lot is made of MMC power consumption here, but the facts aren't completely straight. This is a very important issue (I also think it is in need of review, but for different reasons). Take a look at the power budget. Again, comparing it to O3 isn't really valid, but if you must, consider the hotel loads as a percentage of the total power budget in the intended deployment context (cabled observatories, moos-lite, oasis3).

I think that Raybould and Chaffey should receive a copy of this report before it is widely distributed.

5.1 Religious Wars
Efficiency: This section doesn't seem to actually comment on efficiency, but rather problems with the J9 JVM. 

I don't think that there were any issues with Java's effiency in this project. Whether or not Java is/was a good choice for SIAM depends on a number of factors. The fact that there is only one choice of JVM for this platform did turn out to be a problem, in light of the fact that th J9 roadmap dead-ended a year or so into SIAM development. One could argue that problems encountered with J9 might have occurred in any tool chain or board support package.

Java does offer a very rich set of classes and hardware support; to develop the same system using C++ might have required considerably more development time (and been less reliable?) if we had built some of these things from scratch.

I do think that the boundary between Java and native system code is uneccessarily hard (or that we don't understand it well enough); this does make it difficult to do the "bottom up" parts of the design, and I think the system suffers for it.

Size:
I'm not sure that the comparison of SIAM and OASIS3 is really a valid one. These two systems are targeted at very different applications. While OASIS3 is a robust and efficient controller, SIAM is a more capable and more scalable architecture than OASIS3, designed to solve different problems: 
	automated platform configuration
	scalable networked configurations
	automatic metadata handling
	support of much greater sampling rates
	support of greater instrument power requirements
	more control over instruments
	networked applications
	very strict timing requirements
	ground fault monitoring and isolation of individual instruments
	etc. 

What configuration were you running the MMC in to obtain those power numbers? Do you include the DPAs in these numbers? The LEDs and the ethernet controller consume considerable power, but aren't enabled in the deployed configuration. Some networking capability is required for MOOS, and there 

You argue that Java is to blame for the relatively larger power consumption of MMC. Much of that SDRAM is filled with Linux, which offers a many benefits over the O3 kernel.

In terms of power consumption, I think the real issue is one of MMC instrument fan out. Each MMC supports only 12 instruments; I view this as one of the key limitations of the MMC architecture. If we could amortize the 1 or 1.5 W over 16 instruments or more, the hotel load seems more reasonable in light of the extra features provided. Furthermore, the fanout affects the number of pentrations, enclosure size or number of enclosures (which creates mounting real estate issues), etc.

I do think that a technical review of the system should look critically at the trades made between the power system capacity and the fan out of MMC, but I don't necessarily think that Java has that much to do with the difference in power consumption between OASIS3 and MMC.


Robustness:
Overall, I think that the robustness of the JVM in most areas was pretty good. As I said, I think that it is difficult (or at least not well understood by us) to bridge native system code (power management, timekeeping) with Java code, and it is fair to say that this might be easier if Java were not used. 

5.2 Missing Expertise

I do agree that in there is some lack of expertise in the bottom layers of the design, specifically power management and timekeeping, but it manifests itself as a lack of good systems engineering. With respect to power management and timekeeping, we didn't do a good job of 

	- gathering alternative approaches
	- performing good trade studies and system level design
	- prototyping these elements first

With respect to lack of expertise in data acquisition and instrument control, I don't necessarily see any glaring problems there. What specifically do you refer to in these areas?

I can only think of a couple of people at MBARI who would be technically able to put together a really good architecture for MMC, but they might not be as good at the other 30-40% of the Systems Engineering work that would be required to successfully implement the architecture. 

I think there is both a lack of expertise (people with good hardware AND software skill sets), and in lieu of those people, we (mostly management) could have done a better job at directing and structuring the available resources to design and execute MMC.

5.3 Top-Down/Bottom-Up Design
It is not true that *no* bottom-up design was done, but again, I think that the early phases of the design didn't focus enough on the issues close to the hardware and power consumption.

Besides the question of expertise, I see other problems. It is only within the last couple of years that MBARI has taken a closer look at its system engineering practices, but that was a couple of years too late for MMC and SIAM. 

Also, while I think that many of the XP practices adopted by SIAM were valuable (daily scrums, user stories, quickly evolving prototypes), I think that our XP development cycle had a tendency to direct us to "low-hanging fruit" instead of tackling the hard problems of timekeeping, power management, communications and security that should have been developed first.

5.4 Engineering Process
The fact that the systems used for demonstrations to user groups were always on and connected to the internet was not a problem; the connection was orthagonal to the features being demonstrated. I would agree that before higher level features were demonstrated, that the lower level ones (timekeeping, power management, communications and security) should have been. 

The NMC system did have a wakeup button, which was designed out for MMC...I don't know why, and hope that it can be put back in.

Requirements Input
This section seems to be more about specific MMC issues rather than requirements gathering. Most of these relate back to the fanout of the MMC, which I have already commented on.

DPAs and their extra functionality don't account for a much of the hotel load. Sidearm running at 100% duty cycle consumes about 13% of the 20 W capacity of the MOOS buoy power system. DPAs consume about 1% each, if they are also are fully on 100% of the time. The fact is that the Sidearm runs at a considerably lower duty cycle (more like 60% or lower) and most of the DPAs run at much lower duty cycles (15%). Given that, the hotel load is more like 6-10% -- not so bad, considering what it buys in terms of visibility into the system, not to mention the enabling of features like event detection and response. 

Quite a lot of time has gone into hashing over requirements and trades between complexity and performance.
While I don't necessarily agree with all of the decisions that have been made either, certainly a lot of thought has gone into the decisions taken and trades made.

6.0 Conclusions
I think that there is certainly room for streamlining and greater effiencies in the MMC and SIAM sub-systems. I'm not certain that the entire Sidearm/Linux/Java choice was a bad one, maybe just the implementation of certain parts of it need to be revised. Consider that only now, in the 2004 CIMT deployment, seeing the first end to end field test of the system. We are just now in a position to evaluate the entire system critically and technically, but I think it's too early to say that the implementation is all wrong. 

This document correctly points out a number of flaws in both the design and implementation of SIAM and MMC (and overlooks other sub-systems), which should be discussed and addressed. I think that with some revision, it would be valuable input to a detailed technical review of MOOS.