Hi @xiaoliyu,
There’s a feature comparison between BlueOS and our older Companion software in our documentation (which is also in the process of being updated to cover additional vehicle setup/configuration and hardware support).
At a high level:
- BlueOS provides a nicer interface for configuring and updating components of the vehicle, while also providing a modular system for Extensions that simplifies integrations of custom functionalities and peripherals without needing to run a custom version of the main onboard computer software
- Cockpit takes a similar approach towards control station software, by providing a more configurable and powerful interface for controlling the vehicle, and being readily customisable by users to suit their applications
- There’s a comparison on the way with QGC features that should help display this, along with additional explanatory documentation and content
The primary issues we had with our previous solutions were around extensibility and interface flexibility, which are both critical given our whole company is set up around providing a basis of components and software that others can build upon and optimise to their specific applications.
Just as there’s no single vehicle design that is perfect for everybody, it’s also unreasonable to expect a single software package or interface to be perfect for every application, and given we don’t have the development resources or domain knowledge to develop everything for everyone, it’s valuable for us to instead provide a trusted platform that is intentionally easy to integrate with and modify/configure 
Fair enough. There is another ArduPilot developer conference at the end of October which we’re intending to present at, which may help. That said, I would agree there is scope for additional content/information targeted at comparing our current solution vs the previous one, as well as vs alternatives that are available (although Blue Robotics is not necessarily the best placed to make such content in an unbiassed manner).
I don’t think that’s something we can meaningfully comment on with specific numbers, because even with some sense of who our own vehicles are sold to we don’t necessarily know how they’re used (e.g. for research, or inspections, etc), and there are likely also companies using BlueOS and/or Cockpit without directly using our vehicles.
If it’s helpful / of interest we do have a service providers directory (many of whom use our vehicles/software for at least some of their services), and there’s a map with a rough distribution of recently online vehicles at the bottom of the BlueOS homepage.
We do have some plans for developing multi-vehicle support, but the specifics aren’t set in stone, and some features may end up as an optional add-on so they don’t add bloat and confusion/clutter for the users who don’t need them.
At a minimum, Cockpit having the capacity to know about and indicate the existence of other vessels does definitely make sense (if only as part of showing collision risks), but whether that extends to directly monitoring and/or controlling a collection of vehicles is a separate question.
We are intending to support fleet management in some form hopefully some time next year. That said, the details of that are still very fuzzy - you’re welcome to start a dedicated forum thread or GitHub issue if you have specific ideas or thoughts you’d like to suggest/discuss
As is currently the case, while ROS should generally be able to integrate with our vehicles and software we’re unlikely to recommend it as the primary method of interaction/control for standard users.