This experience is not available in the language you selected.
Proceed
Connect and Monitor Your Products with ThingWorx
Everything you need to implement IoT for remote monitoring
Download Success PathIMPORTANT: When saving the file, in the Print window please do the following: Destination or Printer: select Save as PDF More Settings: In the Options, be sure the boxes Headers and footers and Background graphics are selected.
Connect and Monitor Your Products with ThingWorx
Everything you need to implement IoT for remote monitoring
This is a PDF version of Connect and Monitor Your Products with ThingWorx. downloaded on Date : 2/9/2026 12:44:24 AM
and may be out of date. For full latest version click here.
Overview: Connect and Monitor Your Products with ThingWorx
Use this guide to help you plan, design, develop, and deploy ThingWorx to connect and monitor your products. You will find step-by-step instructions, training courses, documentation, and PTC services to help you along the way.
The information is useful for:
Project Managers
Stakeholders
System Administrators
Technical Staff
Developers
UI/UX Designers
What is a Success Path?
A Success Path is an online guide to help you implement a specific PTC product at your organization. Each path provides step-by-step instructions from the early planning stages all the way through to deployment. Use a Success Path to help your organization get the most out of a product and achieve your business goals.
It’s critical to choose the right use case for your IoT initiative. To start, identify the factors that drive your organization. Then identify the opportunities that could bring the most value. Finally, design your use case to achieve that value.
To gain support, show how your IoT initiative aligns with your organization's goals. Early in the project, identify which factors create the most value for shareholders. How does your organization plan to remain profitable in the coming years? Consult executives to gather high-level business goals.
Common business goals that drive IoT initiatives include:
Improving service efficiency
Improving customer satisfaction
Driving service revenue
Reducing service costs
02. Identify business drivers
Document the specific drivers (activities or capabilities) that will deliver the most impact to each of your business goals and bring value to your IoT initiative. There will usually be multiple drivers for each business goal. For example, drivers that could help reduce service costs may include:
Reduce the mean time to repair
Improve the first-time fix rate
Reduce the number of dispatches or “truck rolls”
03. Identify applicable use cases
Work with a PTC salesperson to identify the use cases, or applications of the technology, that will best deliver against your business drivers.
04. Prioritize use cases
The list of possibilities with IoT can feel never-ending. Rank your use cases to help your organization focus its efforts. This will also help you deliver value.
For each of your possible use cases, create a matrix to identify:
Effort to solve
What level of effort will it take to implement this use case? Consider:
Can the product deliver the data we need?
Do we have the resources we need to deliver this use case?
Does this use case have any prerequisites we need to address?
Does this require any organizational change management?
Value
Quantify the monetary value that this use case will bring to your organization. Depending on the use case, value may come from reduced cost or increased revenue opportunities.
Scalability
Is this use case something that could be applied to other products in your business? If so, how difficult would that be?
Work with stakeholders and subject matter experts from service and product management to make realistic projections. A PTC salesperson can provide insight from third-party research and previous experiences with PTC customers. Get as close to real numbers as possible to help predict potential value.
The matrix will reveal which use cases are viable, of high value, and can increase in scale in the future.
05. Finalize use cases
Work with stakeholders to select the most valuable use case(s) for your IoT initiative. Don’t be afraid to tackle big challenges with big returns. If your use case supports your organization’s key drivers, you’re more likely to get leadership support.
For their first use case, organizations should start with remote monitoring: connecting your products or equipment to collect valuable data. Remote monitoring is a prerequisite for other impactful use cases, and it can deliver value by improving service metrics and/or driving product enhancements to improve customer experience.
Document your chosen use case and confirm it with project stakeholders. Keep your prioritization matrix because it will help you create a long-term roadmap later.
06. Choose software
To implement your use case, you will need a suite of technology solutions. For example, ThingWorx Asset Advisor, ThingWorx Analytics, augmented reality technology, or other solutions may be required. To learn which software is best for your use case, contact your PTC salesperson.
07. Define initial project scope
Make sure that stakeholders agree to the scope of your project. For many organizations, the scope has a substantial, rapid impact. Over time, project leaders will learn, iterate, and solve more significant challenges. Follow your plan and make sure the scope is appropriate for your use case.
Consider questions like:
How many products will be connected at first?
Are there existing processes that must evolve?
How many workers will require training?
What is the rough timeline of your project?
For now, focus on the initial implementation. You’ll build on additional use cases later as part of a long-term roadmap.
Set Goals and Metrics
After you finalize your business use case, identify your goals. Then determine which metrics will help you measure progress. Share this information with stakeholders and the project team to build momentum.
Your goals will depend on your organization’s strategic initiatives and the use case outlined for your project. Confirm the use case and the desired outcome before moving forward. Keep the project scope in mind so you measure the right things.
Identify goals that will address the business challenges within the use case. How will ThingWorx help you realize your use case? All of your goals should be measurable.
Some examples of goals include:
Generate a specific amount of revenue in a specified amount of time
Reduce service costs by a specific amount
Connect and monitor a certain number of products in a specified amount of time
Involve executive and service leadership in setting goals. If your organization has someone leading digital transformation, include them.
02. Determine metrics
After you identify goals, determine the metrics you’ll use to measure progress. As an example, say one of your goals is to reduce service costs by a certain percentage. Your metrics might include how many trips service people make per product and the amount of time they spent on each trip. Other common examples Include:
First time fix rate
Mean time or total time to repair
Percentage of software upgrades performed remotely
Percentage of customer issues resolved remotely
Verify whether you can measure the metrics that you identified. Talk with people in your organization who have access to data or collect data. That way you can set realistic expectations of what is possible. If you’re not measuring these things currently, begin now.
03. Finalize goals and metrics
Collaborate with stakeholders and executive leadership to finalize goals and metrics. Make sure the project sponsor, key leaders, and other team members agree on the goals.
Establish a thorough understanding of:
What the goals are
How metrics will be tracked
Who is responsible for tracking metrics?
04. Document baseline metrics
If possible, document your organization’s “as-is” state, or baseline metrics. This will help you prove that ThingWorx had the intended effect on your organization later. For example, if your goal is to reduce service costs, record the metrics of your current state of service costs before you implement ThingWorx.
In some cases, it may not be possible to get accurate baseline metrics. Maybe you’re not able to measure the right things right now, but you will have better capability after ThingWorx has been implemented. If exact metrics are not available or not accurate, estimate high-level baseline metrics.
05. Document a plan to measure progress
After you identify your goals and metrics, document a plan for how you’ll measure progress and success.
In your plan, outline the following:
Short-term goals of the initiative
Long-term goals of the initiative
Metrics
Roles and responsibilities
Who will track and report performance?
Who needs to be informed?
Key milestones
Baseline metrics (current state)
Other items as needed
Share your plan to measure progress with stakeholders. Refer to it throughout the project to make sure you’re on track.
Assemble Project Team
To achieve your IoT use case, you’ll need an experienced team. Explore the skill sets and experience your project team needs. Determine whether your organization internally employs the right talent. Hire outside resources to bridge any gaps if needed.
You’ll need a variety of contributors to implement IoT. The number of team members will vary, depending on the scope of your use case. Having experience implementing ThingWorx will be a major advantage. PTC, experienced partners, or systems integrators can often fill gaps in skill sets and experience.
Although their titles may differ, typically you need the following team members.
Solution Architect: As the lead technical resource for your Industrial IoT application, a solution architect will design the overall solution. They’ll also coordinate efforts across the infrastructure and development team.
Skill sets needed:
A blend of technical and application architecture expertise
Strong communication and leadership skills
Strong background creating solutions on the ThingWorx platform
Experience with connectivity solutions
Experience with systems integrations design, including the use of REST APIs
Proven track record in building performant and scalable solutions
Software Engineer: Software engineers will develop applications under the direction of a solution architect. IoT solutions development work will typically requires using Agile software development processes. Depending on the scope of your project, you may need more than one engineer.
Skill sets needed:
Familiarity with full-stack development
Proficiency in common development languages, specifically JavaScript, Java, and Python
Experience with the creation and use of Java Extensions
Experience using Eclipse, a Java IDE typically used for ThingWorx development
Experience in the development of systems integrations, specifically using REST APIs
IT Administrator: Your IT administrator maintains your organization’s IT network, servers, and security systems. They’ll also play a role in building and operating your IoT application.
Skill sets needed:
Experience working with scalable, performant systems with a specific focus on the added challenge of high-scale connectivity
Knowledge of maintaining redundancy and high systems availability to avoid unplanned outages
Data Scientist: The data scientist will work to extract meaning from and interpret data. They’ll use tools and processes to fetch the data and analyze it to understand how the organization is performing.
Skill sets needed:
Ability to extract, analyze, normalize, and organize data
Experience with machine learning algorithms and training machine learning models
Deep knowledge of descriptive, diagnostic, predictive, and prescriptive data analytics
Embedded Developer (edge): This developer builds agents and other software that run on the devices processing your IoT data.
Skill sets needed:
Experience developing agents with SDKs for different programming languages
Strong understanding of network communications protocols (i.e. J1939, Modbus), policies, and best practices
UX/UI Designer: Although not critical, a UX/UI designer will design the look and feel of the application interface and make it easier to use.
Skill sets needed:
Proficient in CSS, Adobe Photoshop, Adobe Illustrator, and/or Sketch
Familiar with user-centered design principles
Experience designing mobile, tablet, and desktop applications
Business Process Consultant: Although not critical, a business process consultant will help determine how to best intersect new technology with your business processes to improve efficiency.
Skill sets needed:
Thorough understanding of your organization and specific business processes as they exist today
Experience with process modeling and the creation of future processes
Experience partnering with stakeholders to gather business requirements
Find out whether your organization employs people who have these skill sets. If so, ask the employees whether they can make themselves available to contribute to the project. Get their manager’s approval if needed. You can do most of the work remotely, but team members should be on-site to gather requirements and for the go-live stage.
03. Determine outside resources needed
Typically, organizations hire contractors or consultants to bridge skills gaps and achieve their use case. If internal employees are non-existent or unavailable, hire outside resources. Verify that the individuals you hire have the right skills and experience to meet your project goals.
If you purchased a Success Plan from PTC, you have access to IoT experts who will support and guide you. Customer Success Management can help you plan, implement, and measure your IoT initiative. Your PTC Customer Success Manager will ensure you have the right mix of resources on your team. They’ll help make sure each contributor has extensive experience with the ThingWorx platform and is well suited for the role. If you don’t have a Success Plan, contact your sales representative.
Stakeholder support will be a key asset throughout your IoT initiative. Cultivate buy-in at various levels of your organization, from high-level business leaders to frontline workers. Your most important stakeholder will be at the executive level. Identify a well-respected, well-connected executive champion who will advocate for your initiative on an ongoing basis.
In addition to the people who champion IoT solutions, you’ll also need end users to test them in the real world. Identify a manageable group of workers who will test and provide feedback on early-stage applications. These workers should represent your ideal end users. They’ll help you identify urgent fixes and opportunities for improvement before you implement ThingWorx on a larger scale.
Possible stakeholders may include:
Corporate executives
Service organization leaders
IT leaders
End users
05. Create a team communications plan
Determine how, when, and to whom you’ll communicate throughout your IoT project. Your stakeholders will have different needs, depending on their role.
As you plan how to communicate with your stakeholders, answer these questions:
How frequently will you share information? Some stakeholders will provide daily feedback and direction on the project, while others may get involved on a passive, less-frequent basis.
What’s the best channel for that information? Emails, calls, or meetings may work for some stakeholders and not others.
What information is most important to which stakeholders? Be careful to avoid communication overload.
What do you need from your stakeholders at various points along the timeline? Establishing key milestones or successes in these communications will help to maintain momentum and excitement.
Keep in mind that your stakeholders’ involvement and communication needs may change over the course of the project. Modify your approach as you go.
06. Plan feedback mechanism
While it’s important to communicate, it’s also imperative to listen. If stakeholder communication is only coming from one direction, you risk missing valuable feedback or opportunities to address concerns. Establish channels for soliciting and responding to feedback across your organization. Make sure stakeholders know how to get answers.
Train Project Team
Schedule training courses for members of your project team early. If you’re not sure what your team needs, contact a PTC training advisor.
Determine training needs based on the roles on your team and your chosen use case(s). We have many options to help you start building applications with ThingWorx. For example, we have courses to learn to develop in ThingWorx, how to manage platform security, and a course for DevOps practices, among many others.
Most courses are available through PTC University. A PTC training advisor can help you choose which courses are the most important for your team.
Training delivery methods and cost
Depending on the course, training is available online or in person. We can bring experts to your location, you could join a class at a central location, or participate online.
Costs depend on the course and delivery method. The LEARN Online Subscription gives you access to the entire catalog of ThingWorx courses that you can take online with a live instructor. To find out your options, talk to a training advisor.
To buy or sign up for PTC training courses, talk with a Training Advisor. You can find course listings, descriptions, and schedules at PTC University.
The members of your project team should complete training as soon as possible. This enables each person to put their knowledge to practice as you work towards shared goals.
Define Compliance and Security Requirements
Compile any security and compliance requirements that you need to consider as you design and implement this new technology.
Depending on your industry, there may be regulations or guidelines that impact your IoT project. These guidelines might require:
Restrictions on what you’re able to do
Mandates on things you have to do
Meet with regulatory or quality assurance teams to understand any restrictions or mandates. Document the compliance and regulatory requirements you need to keep in mind throughout the project. Make sure that team members who will build the solution have access to these requirements.
02. Define security requirements
Implementing IoT into your organization requires diligence around security. Your IoT solution requires security considerations for:
Your organization’s infrastructure
The edge, including products, edge agents, connection servers, etc.
ThingWorx authentication and applications
Leaders of the teams who support these items should review our “ThingWorx Secure Deployment Guide.” Document any security requirements that need to be considered for this project.
Make sure that your organization is ready, willing, and able to function in a new business environment. A change management plan and timely communications will improve the value of your IoT solution.
Your IoT initiative will change many things for your organization. Marketing, sales, services, and operations will be affected. Employees will develop new skills, learn new technology, and adopt new ways of working. Customers may also be affected. For some, these changes may be difficult.
To help employees embrace change, plan to:
Communicate consistently
Listen openly to concerns and questions
Encourage participation
Share the benefits that IoT will bring to your organization and its employees
Get leadership to sponsor and promote the initiative openly
Create a change management plan
Create a communication plan
Dedicate resources to put change management into practice
02. Create a change management plan
Create a change management plan to show how your organization will transform from how things are today to how it will be in the future. Make it actionable and specific to your company.
To create a plan, articulate the vision of where the organization is going with IoT. Then identify clear objectives to help you get there.
Your change management process should:
Define a compelling vision
State clear objectives
Secure sponsorship from executive leaders
Build and maintain ownership and accountability
Align processes, organization, and culture
Provide training to enable employees and customers
Enable stakeholder communications
Continuously measure, monitor, and share realized benefits
Document your change management plan and share it across the organization. Remember to encourage participation from employees as you navigate through changes in processes and technology.
03. Create a communication plan
As part of change management, create a communication plan to connect with internal and external audiences. Consider internal stakeholders such as technicians, service management, marketing, sales, and customer service employees. External stakeholders may be vendors, your customer’s customers, or contractors.
Use these questions to guide your communication plan:
Who are your audiences?
What does each audience care most about?
What do they need to know to be successful?
When do they need to know it?
What are the existing or best channels to communicate through?
Who should deliver the message(s) in order for it to be effective?
How often should each audience be communicated with?
What do you need from your audiences at different points in time?
How can your audiences communicate with you?
Refer to your change management plan to answer some of these questions. You may mention the training or materials end users will need to use your ThingWorx application. More detailed information is available to help you plan end user training.
In addition to communicating out, it is imperative to listen. Establish a way for your internal and external audiences to respond to you. They should be able to provide feedback, voice concerns, and share opportunities you may not know about.
Develop a Long-Term IoT Solution Strategy
Plan how your organization will deploy and maintain future ThingWorx applications.
Use your list of prioritized use cases to create a plan for when and how you will build and deploy additional IoT applications. For each additional use case, include:
A high-level production schedule
The resources required
Any training activities needed
02. Determine how to manage the IT system
Assign a team to manage the health of the IT system that supports your IoT applications. This system management team is typically made of IT professionals. Their purpose is to:
Make sure the system is operating correctly
Respond to outages
Monitor the existing system performance and quality
Implement system upgrades
03. Determine how to manage your ThingWorx applications
After deployment, establish a dedicated, central application management team to manage ThingWorx applications and configurations. This team’s purpose is to:
Assess and prioritize changes requested to the existing application
Create and maintain the application roadmap
Determine the cadence in which new versions and iterations are deployed
Schedule new version implementations, including training for end users and the application support team
Make sure applications meet the needs of the organization
04. Determine how to provide solution support
Develop processes for providing post-deployment technical support for your IoT solution. Consider:
Availability
Decide whether your ThingWorx applications are critical to your operations and define your support model accordingly. If it’s a 24-hour-per-day, 7-days-per-week operation, your support must be available on a 24/7 basis. If your operations do not run 24/7, you can adjust availability accordingly.
Align the responsiveness of the support organization with the importance of the systems.
Roles and responsibilities
Who should deliver support? The responsibilities may span different areas. For example, one team may be responsible for issues at the edge and another oversees application maintenance. Your IT team likely has a “help desk” that will be the first point of contact for support. Determine how teams will triage issues among the various experts at different tiers.
Escalation
How will technical support escalate issues that are outside their domain of expertise?
How will they handle complex issues that require additional expertise?
In a tiered support model, the first level of support will engage increasing levels of expertise in the triage process as they work towards determining root cause and ultimately a solution. This expertise may span the varying roles and responsibilities.
PTC support may be contacted for any product-related issues or questions.
The team supporting the end-to-end solution is likely not the same team that built it. The solution should be well documented and handed off to the support team via training that includes not only the support aspects but also how best to monitor and maintain the solution.
To access PTC technical support, log a case with PTC eSupport. Once received, a member of the technical support team will assist you.
After you deploy your IoT project, the project team will transfer ownership to the appropriate application, system, or support management teams. The handoff may take place immediately after go-live deployment, or weeks afterward. Choose the milestone or date when the handoff will take place.
Draft Designs for ThingWorx Applications
To design ThingWorx applications to connect and monitor your products, first learn about your users' needs. Research what data is most important and how users will interact with the applications. Then sketch a first draft.
01. Gather UX requirements for ThingWorx applications
User experience (UX) requirements will help you understand how users will interact with your ThingWorx applications. They define what an application will look like and how the user interface (UI) will work. We recommend that a solution architect and UX/UI designer work together.
To gather UX requirements, do research by talking with experts in your organization. Also, find out who your users are. Talk to the people who will use the data from the application. Find out what data is most important to them and how they’ll search for it in the application. Document this research.
There is not a single way to document UX requirements. Yet, different requirements will result in different UI designs. Requirements may also affect the performance and security of the application.
The research for your UX requirements should answer the following:
Who will use the ThingWorx application?
What language(s) do they speak?
Users may include people in your organization and customers, but have varied roles.
What will they use the application for?
What data is most important to users? Relate this to your business use case(s).
Data styles may include actionable, informational, historical, and payload data.
What type of data is collected informs how ThingWorx processes this data and how to display it.
What kind of data displays will be most useful?
What data can be collected from the edge that will help meet use cases?
How will users interact with edge devices? Are they only viewing data or also causing interactions with the devices? Interactions may include:
Remote sessions
Software content management
Executing applications or scripts at the edge
Requesting file uploads or downloads
How will users go looking for information? For example, will they type in a search field, use a drill down menu, navigate a tree-type hierarchy, etc.?
Does information have to be aggregated for a set of assets?
Do you need to generate any reports for the larger asset or is data more important relative to a single asset?
What levels of visibility and permissions will different users need?
What metadata around assets need to be captured?
Organizational-type information such as owner and manufacturer of the device
Regional information such as region, country, location, address, and geolocation (does it move or is its location static?)
List of contacts regarding the asset
Other grouping of Things such as product lines
Do you have plans to increase the number of products connected over time?
Will the kinds of data that you’re monitoring change over time?
What security requirements will affect the user experience and/or the UI design?
What alerts will the application have and how will users interact with them?
What happens after an alert goes off?
What processes might the users need to follow afterwards?
What other systems may be in the ecosystem that would be valuable to integrate with?
Required administrative mashups in addition to viewing/interacting with edge devices:
Once you document UX requirements, next define user groups. This will clarify what different types of users can see and do in the application. For example, one person may need to look at data but will never make changes in the application. Another person may need full access. These two types of users are in different user groups.
Document the visibility (what they can see) and permissions (what they can do) for each type of user. Be as accurate as you can. If users have too much access, they could see confidential data they should not have. If users have too little access, they may not be able to see the data they need.
In ThingWorx Composer, you’ll create groupings at 3 levels:
Organization
Organizational unit
User group
Different user roles drive what different types of permissions need to be given. For visibility, is it based on a Thing’s organization, location, region, product lines, or other attributes. A user role is an intersection of visibility and permissions. For instance, a user role could be a support engineer (run time permission) for eastern Europe (visibility). Make sure that your user groups and organization units are scalable.
There are 3 forms of permissions you can adjust:
Visibility permissions state what Mashups and/or dashboards a user can see. Assign visibility permissions at an organization or organizational unit level.
Run-time permissions state what services a user can execute and what properties they can access. Assign run-time permissions at the user group level.
Design-time permissions state what a user can modify and access in Composer. Assign design-time permissions at the user group level.
ThingWorx offers built-in user groups for administrators, developers, and users. Depending on your needs, these may be enough to start with. You can set up more user groups, invite users, and make changes to visibility and permissions later.
Design a wireframe, or a first draft, of the user interface (UI) of your ThingWorx application. The goal of the UI is to make it easy for users to get the information they need when they need it.
A wireframe is a low-fidelity, early-stage design. It provides direction to the developers who will build the application. It also shows how users interact with the application. A wireframe often contains a grid of empty boxes that represent elements on a screen. To make a wireframe, you can use a tool like Balsamiq or Axure or draw it by hand.
Focus on what is most important for functionality. Look back on requirements and user research. Instead of filling up the screen with widgets, we recommend that you leave blank space. The fewer elements users see, the easier the application will be for them to learn and use.
In your wireframe, include the following:
Elements on the screen
Use empty boxes to represent the navigation, titles and labels, blocks of text, graphs, images, buttons, etc.
Priority and relationships
Arrange and connect elements to reveal which items are most important.
Interactions
For interactive elements, note how elements respond when a user clicks or taps on it.
Flow
Outline which screen leads to the next if there are many.
Show whether the application delivers alerts.
Preliminary copy
Include words in your design that convey what each element is and does. For example, a heading may say “battery life,” or a button may read “view all machines.” Words can change later in the design process.
Do not include colors, images, or other styling choices. You’ll make those decisions later.
Remember that wireframes change and evolve over time. Later, you’ll review, test, and improve upon your early-stage design.
Plan Integrations and Edge Connectivity
The real power of ThingWorx comes from its ability to pull data from disparate sources into a single application to gain new insights and drive new actions. Plan how you will integrate and connect to the necessary systems and data sources to achieve your use case.
Note the specific pieces of data or metrics you need to build the application for your use case.
How often that data needs to be updated
Does the data being used in your application need to be updated frequently to be useful?
Keep in mind that the higher the frequency of updates, the more transactions your infrastructure will need to support.
What format the data should take
Does the information need to be presented as a number, integer, string, Boolean, etc.?
Where that data lives
Whether in a third-party system, an in-house solution, a .csv file, or something else, identify where this information currently lives.
Whether the connection needs to be unidirectional or bidirectional
Does ThingWorx need to be able to pass information back?
If so, what happens once data is passed back?
Why you need the data
It can be tempting to ask for every data point available for your product, but that often leads to an overload of data. For each piece of data you’re requesting, make sure you know exactly why you need it to accomplish your use case.
Categorize each piece of data to help understand if you need it.
Actionable data typically triggers some sort of action or response. This data tends to be acquired and published near real time.
Informational data represents various properties of your products or assets and typically changes infrequently.
Historical data is used to represent rends or maintain a short-term record of information and events.
Cold storage data is often used for data mining and analytics purposes and doesn’t need to be accessed or seen often.
Understanding what data you need and why you need it will help you have more effective conversations when you’re trying to determine how your organization will actually go about retrieving that data. The requirements you lay out will likely be negotiated and reworked as those conversations continue. ThingWorx collects data in 2 ways:
Integrations: You integrate with systems that house data.
Connectivity: You connect to products, machines, or other physical assets, typically at the edge.
02. Determine integration connectors
When it comes to integration, ThingWorx has a number of integration connectors built in and ready to use but custom-built options could also be needed depending on what kind of integrations are required.
To decide on the best approach for your organization and selected use case, we recommend having a detailed conversation with your solution architect (who has extensive ThingWorx knowledge) and IT and OT experts. Include any others who have deep understanding of the specific data and systems with which you’re trying to connect.
To understand how to gather data from the edge, work with a solution architect and technical subject matter experts. Get understanding and agreement on:
It is critical to your success to create a strong plan for your edge. We recommend working with PTC or an experienced partner to find the best edge strategy for your organization.
Get product data to the edge agent
There are numerous ways to get product data to your edge agent. To understand your best option, find out if it’s possible to either influence the product design to help you collect data directly, or if you’ll need to rely on using logs, files, or databases to which your product sends data.
Consult with the team responsible for making the product, typically Research and Design (R&D). If R&D is open to incorporating software required for your edge within or on top of the product, decide if it’s more efficient to pull or push the data. Either 1) have the agent pull data from the product through something like a REST API or 2) have the product push data to the agent through a web service.
Processing and sending data
Decide if your data will be processed at the edge or at the ThingWorx platform, then determine when and how the data will be sent to the platform. PTC recommends processing data and incorporating business logic at the edge, if possible, in addition to these best practices:
When possible, only send properties to the platform when the value has changed
Also consider the precision required for your data value. For example, if you’re monitoring temperature and only need to know if the value has changed at the tenth of a degree, do not send a change at the hundredth or thousandth level.
Consider using a “deadband” to identify the acceptable range for the property being measured. Only send data to the platform if it falls outside of the deadband.
Build in business logic at the edge to help minimize the load on your ThingWorx server(s).
Choose an edge agent
An edge agent collects data from products in the field and then sends the required data to the ThingWorx Platform. Customers typically choose from 3 edge agent options:
ThingWorx Edge SDK
ThingWorx Edge Microserver
ThingWorx REST API
To choose the edge agent that’s best for your organization, consider:
The skill sets of those building the edge agent. What languages are the developers already familiar with? No matter what agent you choose, you will likely need additional coding to make the agent work properly.
You can build SDKs using C, Java, .NET, Objective-C, and Swift.
You will have to do programming for the ThingWorx Edge Microserver in Lua.
The functionality you want at the edge.
Understand the foundation and basic capabilities provided with each agent. The ThingWorx Edge SDKs are the only agent options that give you access to the source code and are therefore the only options you can fully customize. The other agents will still allow you to build in additional functionality, but the foundation itself can’t be updated or changed.
Once you understand what is included with the agent, explore what additional features you can build and support. Most agent options allow for basic functionality, including file transfer, file browsing, property updates, ability to run service calls, and remote access. Reference the use case(s) and goals you set earlier in the project and make sure the edge agent you choose will help you achieve them.
One of the most important functions to consider is software updates. Not all agents allow software updates at the edge through software content management. You would need to consider alternate techniques, such as building in file transfer capabilities or using field technicians to update each product. Edge agents should never be deployed without an understanding of how they will be updated. Updates are required for security, bug fixes, and incorporating new functionality.
What operating system(s) the agent needs to support.
Where the edge agent will live
Customers typically choose from 3 options to decide where the edge agent will live:
The edge agent lives on a computer that is part of the product itself. If this is the desired outcome, you’ll need to partner with R&D to work out the details.
In a tethered case, the agent lives on a secondary computer that is either attached to the product or lives generally close to the product.
A central agent, often called a “gateway”, is used to monitor and communicate to multiple products.
Once you know where the agent will live, consider how you will monitor the health of the computer hosing your edge agent. You can do this through Windows or Linux calls to check on things like memory and CPU.
The plan you make to collect product data at the edge and send it to the ThingWorx platform will have major implications on your infrastructure. Every decision you make will have an impact on the footprint at the edge and the performance of the platform. Make sure you stay in close contact with your IT team to find the best approach.
The power of ThingWorx comes from its ability to aggregate disparate data into a single place. Structure that data in a way that your ThingWorx applications can use it. Your data model architecture will be a digital representation of everything that provides data in ThingWorx and the relationships between those things.
Your ThingWorx data model is comprised of these entities:
Things are digital representations of all products, assets, devices, systems, people, or processes that provide data.
Thing Templates store core functionality (properties, services, events, and subscriptions). All Things need to be associated with a Thing Template, inheriting its identified functionality.
Thing Shapes also store functionality but can be applied to single or multiple Thing Templates or Things. We recommend using Thing Shapes when there are properties, services, events, or subscriptions that span across multiple Thing Templates or Things across several Thing Templates.
While ThingWorx allows your data model to evolve, spend time determining how to structure your data early in the project. The best place to start: compile a list of Things required for your use case. From there, start to understand the relationships between those Things.
When planning your data model, meet with the developers who will be building the application in ThingWorx. Create standard naming conventions together. These naming conventions should be consistent throughout your organization. They will help keep the information in the ThingWorx platform clean and easy to find. Changing names of items in ThingWorx as an afterthought is challenging and time consuming, so making these decisions early on is important.
This is just a brief introduction to the ThingWorx data model. Use the recommended resources below to learn more and prepare to design your data model. We recommend working with a system integrator, programmer, or developer with object-oriented programming experience.
You’ve decided what agents you need, where they’ll live, and what functionality they’ll have. Now, determine how your agents will be distributed and connected in the field.
If the agent is part of or tethered to the product itself, we recommend partnering with R&D to have the agent creation and custom configurations, such as serial number, built into the manufacturing process.
If the agent can’t be included in the manufacturing process, consider who will be responsible for the installation—a field technician or the end customer. Provide clear documentation or training to help get the agent properly installed and connected.
06. Data mapping
To combine data from many disparate sources into a coherent and compatible data model in ThingWorx, understand the current relationships between the data in existing sources. This is critical to understanding if the data will need to be translated, linked, or manipulated to meet the requirements of your ThingWorx application. For example, ERP may have an asset “ABC” defined but that same asset may be defined as “ABC1” in the EAM system.
07. Document your plans for integrations and edge connectivity
Now that you know which data sources you need to connect to and how you plan to connect to them, compile this information in a documented integration support strategy. This document will help inform other decisions that need to be made. It will help you make any changes to your infrastructure and create a timeline for your ThingWorx project.
Plan Your Infrastructure
Choose the hardware and devices that users will use to interact with your ThingWorx application. Then define an infrastructure architecture plan.
Before you define your infrastructure, determine what hardware and devices users will use to interact with your ThingWorx application. They may use computers, tablets, or other mobile devices. Whatever they need to use will affect how you create your infrastructure architecture plan.
When you identify hardware and devices, consider the following:
Who will interact with the application?
What environments will users be in when they interact with the application? For example, will the application be used in a showroom, an office, an industrial area?
How will users interact with the application?
Will one or both hands need to be free?
Will users wear safety gear, such as gloves, helmets, or eye protection that might hinder their ability to see, hear, or touch?
What screen sizes will the application be displayed on?
Will users move around with a device or interact with the application from a stationary place?
Are there environmental factors to consider (such as temperature or exposure to water, dust, or other elements)?
Based on your findings, you may use existing hardware and devices or purchase new.
02. Define an infrastructure architecture plan
To define an infrastructure architecture plan, involve project members who will work on infrastructure as well as those who design and connect products to the edge. Keep in mind the details from your integrations and edge connectivity plan.
Some topics to consider as you create your infrastructure architecture plan:
Deployment
Will you deploy ThingWorx on-premises, in a PTC-hosted cloud, your own data center, or private cloud?
Availability
Will ThingWorx or applications need to be available at all times?
Is downtime acceptable? Consider both planned downtime (upgrades, updates, maintenance) and unplanned (failures, outages).
Environments
How many environments will you need? How many users will each environment need to support? We recommend at least 4 environments:
Dev: create new applications, features, or work on patches
Test/QA: validate and test new versions, patches, and configurations
Staging: a close replica to your prod environment to do integrated, end-to-end tests such as for scale and load
Prod: host the live, tested applications that users will interact with
How will security requirements affect your infrastructure?
How will security change over time?
Usage
What hardware will you need?
How much processing power and memory will hardware require? Consider:
The number of users who will be accessing data during peak usage
The number of data points that will be called during peak usage
The complexity of the business logic and mashups being used
The total number of connected devices that will be managed by ThingWorx
How often data is sent from each device to ThingWorx
Data storage
What is your data retention and archival policy?
What data will be saved in what database?
How long does data need to be available to ThingWorx in the Mashup?
Networking to support users
Do you have the proper network to support the users of your ThingWorx applications?
What devices will your users be using?
How will end user devices impact the network design?
Consider whether your organization will increase the number of connected products or create additional applications to support other use cases in the future. Refer to your long-term roadmap. Design your infrastructure to meet those needs from the beginning. This may take more time now, but it will be easier to grow later.
When you’re ready, document your final decisions and share them with the project team.
Once you’ve completed your infrastructure architecture plan, compare it to what exists today. Take note of what you’ll need to purchase. Consider how to adjust your design to work within the constraints of existing architecture until you’re able to upgrade.
04. Begin sourcing hardware
If your infrastructure architecture plan requires additional hardware, start sourcing that hardware as soon as possible. This is especially important if the procurement process at your organization requires multiple approvals.
Finalize Application Design
Decide the details of the design for your ThingWorx application. As you create a design specifications document, get input from the developers and solution architects who will build it.
Earlier in the project, you created wireframes outlining your application design. Now create a complete design that provides more detailed information on how it looks and functions. Keep in mind that styling and customization options are limited within ThingWorx.
A design specification document typically includes:
User interaction details: What happens when a user hovers over or taps a button, for example?
Near-final copy: What words will you use for buttons, labels, and navigation elements?
Visual design: What color palette, fonts, and other styles will the design employ?
Data needs: What data will flow into your design? Note where specific datasets are needed.
As you design, consult the developers and solution architects on your team to make sure the components of your design work together. They will use these specifications to build the application later.
02. Review design specifications
Review your design specifications with project team members and stakeholders. Show how the design satisfies user requirements. Ask for feedback about whether the design fulfills the use case and appears usable. If stakeholders have concerns or questions about the design, address them before you begin development.
Determine DevOps and Testing Plan
Determine your DevOps processes for how you will build, test, and deploy your ThingWorx applications. Then document a testing plan.
Establish DevOps (development operations) before you start development. DevOps will improve communication, speed up deployment, and help minimize mistakes.
The developers working on your IoT initiative should establish the DevOps they will follow. ThingWorx development is best suited for an Agile process. Developers will be able to create and iterate quickly. If your developers already have DevOps and follow a different methodology, consider how your IoT initiative will fit in with your current processes.
Include the following in your considerations for DevOps:
Development environments (we recommend at least 4: dev, QA, test, prod Servers)
Source control plan using standard Thingworx import/export, Git, or SVN tools
Naming standards
Acceptance criteria documents and testing plans
Connected products in the field
End user hardware and devices (including branding, look and feel)
Security requirements, organization structure, and user access
Personnel (developers, QA, etc.)
In terms of source control, decide how you will manage code and track work. Naming standards are crucial when developing with ThingWorx. It’s difficult to go back and change naming conventions once you deploy the solution.
02. Create a testing plan
Decide how you’ll test the solution before you deploy. Refer to the designs for your applications, review your acceptance criteria, and confirm your development environments. Developers and device engineers work together to create a testing plan.
In general, we recommend the following testing:
Unit testing: when developing, consider building in a unit testing concept to allow code to be tested separate from UI testing
System testing: test the features and functionality of a collection of components defined by an acceptance criteria document
Security and penetration testing: test for vulnerabilities, risks, and threats (always test with different uses that represent real uses)
Integration testing: test the edge, products, devices, and platform integrations
Stress or load testing: test the stability of the solution and how it handles errors and load
User acceptance testing (UAT): test with select end users to make sure the UI meets their needs
Deployment testing: verify the package works as expected on a staging server that represents a production configuration
Identify what testing you need to do in each of your environments. There may be additional testing you need to do that was not mentioned but are based on your specific solution or industry. Remember to consider security and compliance requirements at every stage.
Create a testing plan for each application. Align testing with your DevOps processes. Plan to test in a QA environment that replicates your production environment as closely as possible. Make sure that your tests replicate what it’s like in the real world otherwise the tests will not be valid. We also recommend that your developers agree ahead of time that they will only write code in your dev environment (not test, QA, staging, or prod). This will prevent confusion and inaccurate test results later.
03. Document testing plan
Next, create and document the plan for how you will test the solution. Be as thorough as possible. In your plan, include the following:
Value statement
Summary of what the solution does (refer back to your use case)
Data sources and data flow
Design specification
Acceptance criteria
Test procedure
Environments and who has access to what
Security requirements
Naming conventions
ThingWorx version or release numbers
Results of quality assurance (QA) test
Performance figures
Revisions
Software
You may not have some of this information until you start testing. As you test, add in what new information you receive and document code as you write it. If you keep your documentation brief and tight, you will find a rhythm as you move forward. Your documentation will give you evidence to solve issues and make decisions faster.
Plan for Adoption
Make sure you have the right documentation and training available to enable your organization to adopt your IoT solution successfully.
Those in your organization who support your IoT solution and use your ThingWorx applications will rely on documentation during and after deployment. There may be stakeholders outside your organization, such as your customer, who will need documentation, too. Identify what you need now so that you can create it along the way.
Create a list of the personas in your organization who are involved in creating, supporting, and using your IoT solution. Then articulate what they need included in documentation to do their jobs.
Here are some examples of audiences who may require documentation:
Developer
System administrator
Solution architect
Designer/user researcher
Application support team
Customer service
Edge implementer
Internal end users
External end users
Service organization
Consider when, how, and to whom documentation will need to be available. Once you define each audience, and their documentation needs, communicate this within your organization. Individuals responsible for creating documentation will have a clear picture of what needs to be included. Useful, timely documentation will enable successful adoption of your IoT solution.
02. Plan end user training
Identify who your end users are and what they need to adopt the new technology. End users of your ThingWorx applications may be employees, vendors, and customers. They need to understand how the solution was built and how it works in order to do their jobs successfully. This is especially important for super-users—those in positions to help or direct others.
For your use case, end users might be:
Service technicians
Service managers
Customer service employees
Vendors
Customers in the field
Each may need different levels of understanding and education. Determine what training and mentorship opportunities you can leverage or need to create. You may need technical documentation, presentations, or instructional material.
PTC can partner with your organization on training, mentoring, and developing materials. We can help train key individuals who will then be able to train others in your organization.
With your IoT initiative planning nearly complete, next compile a final list of project costs.
Add up the final costs of:
Equipment such as hardware, software, and networking
Internal and external resources
Any potential financial impact this project could have on current operations due to outages, shortages, etc.
We recommend that you include a 10-15% contingency on your final budget to support unplanned costs that may come up during the project.
02. Document final project plan
Your project plan should provide a detailed view of everything you need to do to complete your project. This plan should include:
Specific tasks
The people responsible for tasks
When each task needs to be completed
Use the documented strategies you’ve created so far as your starting point. No task is too small. Include everything from development and launch tasks to training and communication plans. Also include critical project milestones you can report back on to your stakeholders.
03. Get approval on the final budget and project plan
Take your detailed costs and final project plan back to your executive stakeholders for final review and approval.
Set Up Your Account
Before you start using the software, create a PTC eSupport account. You’ll use the account to access software downloads and get technical support.
Create a PTC eSupport account to download ThingWorx software and get technical support.
When you create your account, provide one of the following numbers:
Your Service Contract Number (SCN)
Your Sales Order Number (SON)
Your Site Number
PTC will send a software order fulfillment email after your purchase is complete. That email will give you the information listed above. If you can’t find the information you need, submit this form to get help.
Configure the infrastructure that will support your IoT initiative. Then, install the ThingWorx platform and any other software needed for your use case.
Set up your infrastructure according to your documented architecture plan. This includes any servers, networking, hardware, and devices needed to support ThingWorx across your organization. Prioritize the hardware and servers you need to get your development environment up and running so you can start developing your ThingWorx application as soon as possible.
Before you begin, review the “ThingWorx System Requirements” document. Make sure you’re ready for installation.
To install the ThingWorx platform, log in to PTC eSupport. Select “Download Software.” Detailed installation steps are available in the “Installing and Upgrading ThingWorx” guide.
03. Install or import additional software for your use case
If your use case requires additional ThingWorx software that your organization purchased, download it at this time. Log in to PTC eSupport. Select “Download Software.”
If you are not sure what software your organization has purchased, you can look it up. Select the option to “Download Software by Sales Order Number (SON).” You’ll need your customer number and sales order number if you need help identifying additional software, contact your PTC salesperson.
Additional software may include:
ThingWorx Analytics
ThingWorx Connection Server
ThingWorx Edge Microservers
ThingWorx Edge SDK
For detailed installation steps, find the applicable installation guide in the PTC Help Center.
Make sure your organization’s security measures will allow ThingWorx to communicate with your systems. Work with your IT or network infrastructure team to plan how data will pass from your network to ThingWorx. In some cases, network firewall(s) will block connections, which will prevent your integrations from passing data to ThingWorx.
Create the structure for grouping users. ThingWorx will assign user permissions (what the user is allowed to see and do) according to the groupings you set up. You can also set permissions at an individual user level. Create groupings following the structure you designed earlier in the project.
Establish the user group framework so that you will be able to test the application properly. If needed, provide ThingWorx credentials to stakeholders or other users who will help you test the application. Make sure they have access to what they need. Later, you’ll provide accounts to everyone at your organization who’ll use ThingWorx.
02. Add initial users
Provide ThingWorx accounts for the team members developing your ThingWorx applications. Add initial users in ThingWorx Composer. ThingWorx includes a default “Administrators” group. Users in this group have access to everything. We recommend you assign developers to the “administrator” group, which will provide the permissions they need to develop and validate the application.
Focus on creating user accounts for developers and other team members building the application. You’ll create user accounts for end users of the application later.
Based on your infrastructure and testing plan, build a DevOps pipeline for continuous integration. A pipeline will minimize possibilities for human errors by automating how you compile, test, and deploy code through your development environments. It will also help you identify errors and monitor the solution once it’s live in production.
There are different tools you can use to build a DevOps pipeline. Some examples include Jenkins, Git, or Tortoise. Since there is no single way to build a pipeline, just make sure it aligns with your DevOps, testing plan, and infrastructure. It should show where the data comes from and where it flows.
Depending on your organization, someone from IT, quality assurance, the development team, or a security expert may build your pipeline.
02. Create asset simulator
Before you begin testing your solution, create an asset simulator. It will enable you to test the solution under conditions that closely resemble the real world. An asset simulator is supposed to behave like products in the field. The more realistic your asset simulator and testing scenarios are, the more accurate your testing results will be.
We recommend that a developer builds an asset simulator with someone else in your organization who is familiar with how your products behave in the field. That way the developer will understand what best represents an effective simulation.
Implement Edge Connectivity Strategy
Establish connections to edge devices that enable ThingWorx to communicate with your products and systems.
Guided by the plan you created for edge connectivity earlier in the project, build your edge agents. Develop the executables that will get data from your products to the ThingWorx platform.
Make sure your edge is secure by referring to your security requirements created earlier in the project. Consult the “ThingWorx Secure Deployment Guide.”
Once your edge solution is built, verify that the data is flowing from your product to the ThingWorx platform through the agent as expected.
Make sure:
The data appears in the correct format/structure
The right amount of data flows through
The speed and performance are acceptable
If your testing plan included testing edge components, follow that plan. Troubleshoot any issues before you continue with deployment.
03. Implement ThingWorx data model
Use ThingWorx to model the data from your products and systems. The data model specifies relationships among data points and provides the framework for your IoT application. Follow the data model design you created earlier in the project.
Data tag mapping involves labeling data from a product, machine, or system and linking it to your data model in ThingWorx. Tag data specifically so ThingWorx can find and use it.
Data tag mapping can be complicated and time consuming. A programmer within your organization, a third-party vendor, or the R&D team developing the product may be able to help.
Build Integrations
Connect to the systems that will supply the data you need for your applications. ThingWorx offers a variety of pre-built connectors, but some third-party systems require custom integration connectors.
Connect to third-party systems, assets, and/or tools your use case requires. Follow the integrations plan you created earlier in the project. A solution architect can help determine which connectors you need to extract data. If possible, work with an expert who understands the system you’re connecting to. Also, consider how network configuration will affect your connections: some ports may be blocked or have stricter security in a production environment compared to a test/QA environment.
If needed, build custom integrations to the systems, assets, and/or tools your use case requires. In most cases, you’ll use REST APIs to create integrations. The configuration will be necessary within the system you’re connecting to. A solutions architect can help determine how to build these connectors. If possible, work with an expert who understands the system you’re connecting to.
Work on a standalone server as you implement connectors. You will need to restart the server several times for ThingWorx to recognize new connectors. Restarts will interrupt others who may be working on the servers or anything connecting to it.
03. Validate connectors
After you put connectors in place, verify the data flows from the source to ThingWorx. Make sure:
The data appears in the correct format/structure
The correct amount of data flows through
Data from ThingWorx flows back into the connected system (if your connection is bidirectional)
The speed is acceptable (the system does not time out before completion of data transfer)
If needed, troubleshoot any issues before you continue with deployment.
Guided by your design specification document, build the IoT application in ThingWorx. Verify the resulting application satisfies your business and user requirements.
Based on the final design specification document, the designer and/or developer will use ThingWorx Composer to build the application user interface.
It’s helpful to understand these components within ThingWorx:
Mashups are webpage visualizations that deliver information from the ThingWorx model
Widgets are the components that make up the Mashup, such as text boxes, buttons, and navigation links
Data services call data into the Mashup
We recommend you connect some data at this stage. It’s not necessary to have all the data you need before you begin development. But designing with real—albeit incomplete—data will eliminate the need to manufacture dummy data. Ideally, all your data should be ready within a few weeks after development begins.
Verify the design is working properly, the data is flowing correctly, and the widgets work correctly. Iterate as needed until everything works. If you don’t have data to work with yet, use dummy data to check your work. Later, you will test the application more thoroughly.
During the planning phase of your IoT project, you outlined a process for managing code across environments (DevOps). As you develop your application, all developers need to follow the agreed-upon DevOps processes. As you create and test solutions, your DevOps process ensures your work is backed up. DevOps also prevents team members from accidentally overwriting or deleting pieces of the application.
03. Review application design
When your application is nearing completion, confirm whether it satisfies your use case, application requirements, and user requirements. Perform this step several weeks before the planned go-live date: give your team enough time to fix any issues that may arise. If you built your application in house, consider engaging PTC’s ThingWorx experts to review your solution and identify possible risks.
In the next phase, you will test the application to verify the data flows correctly and users can access the information they need.
We recommend you create documentation that details how the application was developed. After deployment, the team supporting end users will need this documentation to troubleshoot issues and fix bugs.
Test and Validate the ThingWorx Solution
Deploy your IoT applications for testing and follow your DevOps and testing processes. Then decide whether to promote your solution to production.
Deploy your ThingWorx applications to your test or QA environments and follow your DevOps processes. Make sure you know:
What your environments are and who has access to them
Release numbers
Naming conventions
Be aware of the capacity you need in each environment to test as you go. Some of your environments may be temporary but serve specific purposes. Document your work through this process.
02. Verify user permissions and data
Make sure users have access to the right components within the application. Have several users log in to ThingWorx in a test/QA environment. They should verify they have access to everything they need. Test the user permissions for each user group (administrator, developer, user, etc.). If someone can’t access a mashup or if they have too much access, change their permissions.
Also, verify that each environment shows the appropriate data for each user group. You may need to strip production data from some environments. Do this to prepare for testing, especially user acceptance testing.
03. Cutover integrations
Transition your integrations to start feeding data into ThingWorx. After you turn on the integrations, verify the data is flowing from the asset/tool/system as expected. Make sure you’re not receiving extraneous data.
If you’re moving from a legacy system, compare the data from the old system with what you see in ThingWorx. The data should be identical. Monitor the data for several hours before you continue through deployment.
04. Execute testing plan
Follow the testing plan you created earlier to thoroughly test the application(s) and verify the package. Testing is an iterative process. If you find issues, go back to your development environment to fix them. Do not make any changes to code in environments other than your development environment. Remember to document code as you write and record test results.
Test the application in a test/QA environment with a few potential users (service technicians or other available participants) to make sure that what you built meets their needs. User acceptance testing should answer questions like:
Can users navigate and use the application?
Is it what they expected? Is anything confusing?
Is it missing any functionality that their system of record has today?
Did the application function correctly during the test?
You may get insights during testing and choose to act on them later. If the application does not meet all user needs, decide whether to pause deployment or to launch as-is.
05. Promote the solution to production
Once you perform testing in your test or QA environment and you’ve verified test results, decide whether to promote the code to production. Going to production will “publish” your application, deploying it to the field. Make sure you have a backup in place before you promote to production. If you followed a DevOps process, your work should already be backed up.
To promote to production, the developer/architect will import data and entities to the production server. If issues come up, do not make changes to the application in the production environment.
Once the technical team successfully deploys the application, give an update to the project team members and stakeholders. The application is now collecting real data, communicating with your assets, and is available for use.
Prepare Team for Deployment
Make sure the workers who will support and use your ThingWorx applications are ready for go-live.
Document how you designed and implemented your edge solution and IoT application(s). This documentation is crucial for supporting and using the edge and applications. We recommended you document the solution as you build it. Now compile the various documentation pieces your team created throughout the project.
Documentation should include:
Organization structure: Who is assigned to which user group within ThingWorx?
User and group permissions: Document the permissions granted to each user within ThingWorx. Specify visibility groups and runtime groups. For example, document whether your application grants developer users permission to view service X, but not service Y. This will help your support team quickly resolve issues that may come up after deployment.
Application details: How do services, data, and mashups interact? Document where your data flows into which services and mashups.
Edge details: Include information about the basic foundation and custom-code executables required for your edge agents. Also, provide details on how to make updates at the edge.
Basic end user information: Provide instructions to the workers and customers who will be using your IoT applications.
Create documentation on how to use the application and how to get support in case of issues. This is the only documentation your end users will need. Keep the documentation consistently updated. When you make a change to the application, update the documentation to reflect that change.
02. Add admins, support, and end users to user groups
If you have not done so already, add your administrators, application support team, and end users to ThingWorx. Follow the plan you created to assign each user to the appropriate user groups. Make sure these users have permission to access everything they need within the application.
03. Train internal end users
Train those who will use your IoT applications. The depth and format of your training will vary, depending on its complexity.
Ensure your end users know:
How to use the application
How the application will affect their job or role
How to navigate the application on different devices (desktop computers, tablets, etc.), if applicable
How to get help from the support team
Where to access documentation
How to troubleshoot and report errors
Inform end users when the application will go live. A few weeks after deployment, follow up with them to get feedback.
04. Train admins and support
Train the teams who will give technical support to end users after deployment. Make sure they’re familiar with the application documentation and understand how the solution was built.
Your support organization must learn the set up of your organization structure and user permissions. Some of the most common issues that ThingWorx users encounter are caused by user permissions. For example, if a user does not have permission to view a specific page, they will get an error message when they try to access it. With the right documentation and training, your support team will be able to quickly resolve this issue.
Deployment Support
In the weeks after you deploy your IoT application, you’ll provide intensive hands-on support. Prevent downtime by anticipating and quickly resolving issues.
During and immediately following deployment, the project team who built your IoT solution must be readily available to resolve issues. They should also know how to reach IT, if necessary.
If your application is running 24 hours per day, 7 days per week, then 1-2 employees should be reachable outside of normal business hours in case of emergencies. If you thoroughly tested the system before deployment, emergencies are less likely.
Deployment support typically lasts 7-14 days and ends when the solution is functioning as expected. There may be ongoing bugs or minor fixes that developers address later.
02. Handoff to application support team
After deployment support has ended, the team who built your IoT solution will transfer ownership to your designated support organization planned earlier in the project. This team is responsible for providing technical support to ThingWorx users, among other duties. Ensure the application support team is trained and prepared to resolve potential issues.
After handoff, your support organization should never make changes to the application in production. If there is a problem, make the necessary changes on the development server, test them, and then publish them to production. Finally, note the change in the documentation.
Measure Business Impact
Revisit the goals and metrics you established for your Industrial IoT project. Then, gather the data you need to measure success.
Revisit the goals your organization set earlier in the project. Then, gather the metrics for your current state (now that your IoT application is functioning as expected). If you don’t have access to the data you need, reach out to the project leader. Finally, compare the post-deployment metrics to the goals set for your project.
We recommend you wait 30-90 days—depending on your use case—to gather post-deployment metrics. While it’s likely your organization will see improvements almost immediately, some metrics require several weeks of data to properly measure, especially if workers are slow to adopt the solution. Account for unplanned benefits that IoT has provided to your organization. There may be less-tangible value to your operations that’s worth highlighting.
Share the results with the project sponsor, organizational leaders, and other stakeholders.
Do not duplicate or distribute this downloaded file without written permission from PTC.
Overview: Connect and Monitor Your Products with ThingWorx
Use this guide to help you plan, design, develop, and deploy ThingWorx to connect and monitor your products. You will find step-by-step instructions, training courses, documentation, and PTC services to help you along the way.
The information is useful for:
Project Managers
Stakeholders
System Administrators
Technical Staff
Developers
UI/UX Designers
Get started
What is a Success Path?
A Success Path is an online guide to help you implement a specific PTC product at your organization. Each path provides step-by-step instructions from the early planning stages all the way through to deployment. Use a Success Path to help your organization get the most out of a product and achieve your business goals.
Product Documentation
Find step-by-step instructions and information about using the ThingWorx Platform and ThingWorx applications in the Help Centers.
Ask the Community
Visit the PTC IoT Community to get product assistance, share ideas, and browse information about using ThingWorx.
Technical Support
Log a case with eSupport using your Service Contract Number. Don’t have it? Ask the Community.
Contact Us
Have a question? Submit your contact information and we’ll reach out within 1 business day. You’re never obligated to purchase or commit.
Support Portal
Contact an Expert
Training and Skills
Join the PTC Community