- Gentlemen, welcome back to Innovator's Corner.
I'd like to introduce you to Mr. Calvin Chung
who will be from Eastman TARDEC
and he'll be talking about Autonomous Ground Vehicle
Reference Architectural Review.
Thank you.
- Good afternoon everyone.
My name is Calvin Chung from TARDEC
and I'm here to tell you about
the Autonomous Ground Vehicle Reference Architecture
otherwise known as AGVRA.
So, first off I just want to zoom back out
and look at the bigger picture.
The robotic and autonomous systems
or RAS strategy is the strategy
that the Army is using to look
at how they want to implement robotics
and autonomous systems in the near and far term.
It talks about how we want to do a lot of capabilities
such as increasing situational awareness
and increasing force protection
and in order to do these things we need greater capabilities
in a lot of software intensive systems
such as autonomy, artificial intelligence,
and common control.
The bottom line here is that implementing the RAS strategies
is going to require a lot of development
and some software intensive systems for us
to be able to leverage rapidly advancing technologies.
So, what are the challenges in this?
Overall, when trying to acquire and develop
software intensive systems,
there have been a lot of challenges
in government acquisitions.
There's often cost and schedule overruns
because planning software is difficult.
There is high maintenance costs
and limited reuse across programs.
This is because a lot of development
ends up being closed shop efforts
with little reusability between different programs
and overall, the rate in which technology advances
in industry is slower than the rate
in which it was brought over to the military domain.
In order to help solve some of these problems,
the RAS strategy talks about using
Open Standards in Architectures or OSA.
Through using Open Standards in Architectures
we can get some cost savings by having commonality
between software components and platforms.
It allows us to do faster upgrades and support innovation
with accelerated capability development
and it gives for greater modularity
to have better integration between different mission sets
and the use of Open Systems in Architectures is nothing new.
It's been used in industry,
things such as web protocols, mobile operating systems,
even shipping containers have leveraged
the use to great effect to have a lot of savings
and commonality between different companies.
Despite the usefulness, there are challenges
in using OSAs.
In order to use the OSAs you need to have careful planning
to make sure that all the different standards
and architectures that you want to leverage work together.
Even within the Army itself,
there are dozens of different RAS relevant standards.
However, there's no good documentation
explaining how they work together.
There are things such as IOP, Victory, Faced, etc.
A lot of different standards and architectures
but there's no high level guidance that tells us
how to bring them together in a robotic system.
Overall, the bottom line is that guidance is needed
to effectively implement
this Open Standards in Architectures strategy.
And that is where AGVRA comes in.
The high level purpose of AGVRA is to provide
a set of guidelines to enable the robotics community
to fulfill the RAS strategy allowing us
to have modularity and common standards
to have affordable development
and advancement of technology.
Overall, we'll broadly increase our understanding
of OSA and increase innovation
by reducing the integration burden.
The objectives are basically to leverage
the best software behaviors,
to enable code reuse and modularity,
to fuse development and testing,
and to be able to let vendors
leverage their expertise in niche areas
as opposed to having to start from the ground up.
So the bottom line here is that the AGVRA
provides technical guidance for the implementation
of the RAS strategy.
This lays out the development plan.
Right now we just finished out phase zero
which is the concept description.
In this phase we looked
at the architectural concepts overall
and helped give some guidance about how they should
be applied to different development programs.
We did a survey of current and existing standards
and open architectures to let people know what's there,
what's ready for use, what needs further development.
And we also looked at some current
and near future implementation architectures
to talk about how they are currently being used.
As we go on, we're going to further develop this
by having architecture descriptions
and actually reference implementations
and this will have actual technical implementations
and reference plans
so that we can have something that everyone
can look through to develop robotics
to have commonality across systems.
Something important to note here is that
as we further on develop this idea we
are increasing industry leadership in this as well
because this is meant to be
a joint government and industry effort.
This isn't solely government.
We need to work together to make sure
that we're all on the same page
as we move on to develop the capability.
This goes through how the concept description came about.
The important thing to note here is the participants.
In developing this, there are many groups across TARDEC.
We brought in many open architecture SME,
Subject Matter Experts,
such as the Chief Architect at Victory,
one of the lead developers of UCS.
In addition, general subject matter experts
in the robotic autonomous domain.
We've been working very closely with MIT Lincoln Lab
throughout phase zero and we'll continue this relationship
as we go on to the development of AVGRA overall.
This slide is just to show that in order to do this,
we had to take a top down and bottom up approach.
Top down in that we had to look
at higher level architectural concepts
to be able to properly explain and understand them
to the different programs that need to utilize these things
and bottom up in that we looked
at the current existing architecture standards
and programs to see how the Army's currently utilizing them
and to make sure everything fits together
in a way that is actually well understood.
This slide goes through the different sections
of the concept description.
Some things I'm going to focus on are the stakeholders,
the architectural viewpoints and quality attributes,
and the analysis of all of our architecture efforts.
So, for stakeholders.
In order to properly determine the stakeholders,
we examined the RAS operational concerns,
the RAS technical objectives,
and Better Buying Power 3.0
and through looking at that and running through
the ISO 4210 architecture description,
we determined that the relevant stakeholders
are there listed on the screen.
There's the Army user community,
(mumble) community, R&D community,
test and evaluation community, contractors and vendors,
and the standards and technology development community.
And using those stakeholders and the documentation
from the RAS and Better Buying Power
we helped determine some high level concerns
that those different stakeholders care about.
So basically, the different stakeholders
will have different problems or areas of things
that is in their domain
that they care about when developing RAS.
So what somebody needs who is a army user
is going to be different than a army R&D developer needs.
So by mapping the concerns out
to the different stakeholders,
we're able to properly address
what they actually need to move forward.
And using those stakeholder's concerns,
we're able to create different architectural viewpoints.
So these architectural viewpoints is what those stakeholders
should use to solve the problems relevant to their domain.
For instance, someone in the PO office
will have a greater concern over what
the general open business model architecture is
versus someone in the Thanes community
which will not care about such a high level
of what things are but will need to know more
about the target systems architecture.
So with those stakeholders, concerns and architectures,
we're able to create a list of quality attributes
to help those stakeholders rate what architectures
actually fit their needs.
So the quality attributes can actually be used
to inform what architectures to use
based on the qualities important
to the different stakeholders.
For instance, this lists
the business participant architecture
so if the stakeholder cares about government collaboration,
then the architectures that they need
would have to have good ownership boundaries,
governability, manageability, and security.
So where that all comes together
is the architecture survey that we provided.
In doing the architecture survey,
what we did was we looked at existing standards
and architectures relevant to AGVRA,
did a characterization and comparison of everything,
and looked at the different architectural viewpoints
to figure out what the different quality attributes
existed within the different architectures.
This benefits everyone greatly because it allows us
to leverage work done prior in defining the standards.
It can leverage lessons learned from these previous efforts,
identifies the strengths and weaknesses
of these different standards and architectures
depending on what your focus area is,
identifies areas of commonality,
and it provides an initial assessment
of how this relates to the AGVRA
and how it can be brought together in a coherent system.
These next two slides show a list
of some of the architectures and surveys shown.
As you can see here, it goes through the effort categories,
the effort objectives, domains.
The actual document itself has a lot more information.
I think it combines 300 pages,
so it's a pretty beefy document.
But note that if you look at the effort category,
we didn't just look at the RAS architectures,
there's an Abeln Technologies
that we had to keep track of
because those are important to the development as well.
So we had to make sure that everything
that we looked at that had Open Standards in Architectures
was properly accounted for.
And with the survey and with the architectural concepts
that brings together everything
for the initial concept definition.
Future works that we're going to further explore
to find the requirements
of the different architectural realms.
We're going to investigate the feasibility
of having AGVRA technical architectures
which will combine the existing architectures
to have the reference to show how to use everything
in the development of the system.
We're going to develop the requirements
and recommend an approach
for our data information architecture
and we're looking to develop and recommend
a strategy for model-based system engineering
to help stakeholders have a method
to generate program requirements,
evaluate coverage of existing artifacts
and automate acceptance testing.
So that's AVGRA in a nutshell.
If you have any questions, I think you can ask them now,
or if not, I'm in the booth back there in the AGVRA area.
Thank you for your time.
- George Fules, Army (static) Group.
Do you have any plans right now to socialize this thing
with the other services or SOCOM
or the other groups dealing with autonomy
in order to make this broader
than just TARDEC and army baseline
- Yes, we do.
Let me see if I have it on the timeline.
It's supposed to be released in April for government review.
Right now we're going through internal review
and then after we do the internal review we're going
to socialize it to the greater government group
and then to industry as well.
So there is definitely plans to socialize this,
to make sure that,
cause we don't want this to be a TARDEC thing.
We want it to be a government/industrial thing
because for this to be successful everyone
has to be on the same page
with the use of standards in architectures.
So actually if you want to come stop by my booth later,
let me get your contact information
and we'll be sure that your group is involved.
Okay, if there are no other questions or comments,
you can find me over there.
Thank you very much everyone.
(clapping)
For more infomation >> Sacramento Sheriff Releases Dash Cam Video Of Protester Struck By Deputy's Vehicle - Duration: 2:25. 
For more infomation >> Man critically injured after being trapped under vehicle - Duration: 0:33. 
For more infomation >> Don't Pay Toll If Your Vehicle Crosses Yellow Line with Proof | Share It Now with Everyone - Duration: 4:52. 
Không có nhận xét nào:
Đăng nhận xét