I suggest you use the line feature as the "observer" input for the Viewshed tool. I think this is a simpler method than trying to generate points 10m offset from the line feature and then use Viewshed on that set of points.

The "standard" Viewshed outputs a binary raster, composed of visible (1) and not-visible (0) values. However, ArcMap's Viewshed is pretty flexible, and will accept a line feature as the "observer". In this scenario, the resulting visibility raster provides a count of how many points along the line can see each cell. If your line is 10 observation points* long, for example, the raster values would range from 0 (no points-on-line can see that cell) to 10 (all points-on-line can see that cell).

* I'm fairly sure that the number of points it generates along the line depends on the DEM resolution; for example, if you've got a 100m line and a raster with 10m cells, your line will be analyzed as 10 points.

Since you want to include height of your points of interest, you will need to include OFFSETA and OFFSETB information in the attribute table. OFFSETA is the height of the observer (the line, 1m), and OFFSETB is the height added to the "target" cell (1.5m) during analysis.

To account for visibility interference from vegetation, you will need either:

1. a DSM (digital surface model, includes elevation values of non-terrain features such as trees);
2. a DEM (digital elevation model, bare earth terrain), add 20m to account for tree height.

I suggest you use the line feature as the "observer" input for the Viewshed tool. I think this is a simpler method than trying to generate points 10m offset from the line feature and then use Viewshed on that set of points. If an observer can see part of the line, then that point on the line can see the observer, and so we can use them interchangeably.

The "standard" Viewshed outputs a binary raster, composed of visible (1) and not-visible (0) values. However, ArcMap's Viewshed is pretty flexible, and will accept a line feature as the "observer". In this scenario, the resulting visibility raster provides a count of how many points along the line can see each cell. If your line is 10 observation points* long, for example, the raster values would range from 0 (no points-on-line can see that cell) to 10 (all points-on-line can see that cell).

* I'm fairly sure that the number of points it generates along the line depends on the DEM resolution; for example, if you've got a 100m line and a raster with 10m cells, your line will be analyzed as 10 points.

Since you want to include height of your points of interest, you will need to include OFFSETA and OFFSETB information in the attribute table. OFFSETA is the height of the observer (the line, 1m), and OFFSETB is the height added to the "target" cell (1.5m) during analysis.

To account for visibility interference from vegetation, you will need either:

1. a DSM (digital surface model, includes elevation values of non-terrain features such as trees);
2. a DEM (digital elevation model, bare earth terrain), add 20m to account for tree height.

The final challenge is looking only at points 10m away from your line. MappaGnosis's suggestion of using RADIUS1 and/or RADIUS2 will limit the Viewshed analysis to only those raster cells near your line (and not, say, points a mile away that you really don't care about which are only going to increase the tool's execution time).

You could also try creating a 10m buffer around your line, clipping the Viewshed results to that polygon, and looking at the values in the clipped raster.