Hi, Vamshi - yes, you need to restart runtime in order to pick up the new package. Moreover, runtime caches the package locally, so when you restart you need to make sure that Robot manager connectivity is on and that runtime is able to register successfully and pick up the new package.
Yes, there will be a set of features in conjunction with the release of Robot Manager v 6 (planned for December of this year) that will achieve the goal you are intending, however it still won't just update the package for the runtime on the fly. Together with an RPA Service (that will manage runtime logins and starts) RM console will provide the following:
Ability to Start / Stop Robots from RM;
Ability to Move robots between work groups;
Ability to schedule robots to start / stop / move.
In your scenario once the package is updated and assigned in RM, you will be able right there in RM to order the runtime to be restarted, which will achieve the desired effect. The key here is that you will also need to install and have RPA Service running on the bot VM because on-demand restarts is a concerted effort between RM, RPA Service, and Runtime.
Currently the RPA Service takes its schedule from the local configuration, but with RM 6 it will get instructions directly from RM. So the enhanced RPA Service is based on the one that is already available, just more centrally connected and it will have scheduling and on-demand start/stop capabilities extended.
Of course, to take advantage of the new features you will need to upgrade your RM, Runtime, and install the newest RPA Service.
Yes, RM is a Pega application and it is essentially a "management console" for bots. RM itself doesn't host the bots and doesn't perform automations. Automations are executed by Robotics runtimes that are installed on Windows machines where you have access to all these application types.